The latest articles on DEV Community by zhan jianping (@zhan_jianping_43b53afc14f). https://dev.to/zhan_jianping_43b53afc14f https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3949014%2Ff81016df-52e6-4c2d-bafc-4a6c5619e2d7.png https://dev.to/zhan_jianping_43b53afc14f en zhan jianping Sun, 24 May 2026 12:24:15 +0000 https://dev.to/zhan_jianping_43b53afc14f/how-i-built-a-browser-based-image-compressor-that-never-uploads-your-files-4no2 https://dev.to/zhan_jianping_43b53afc14f/how-i-built-a-browser-based-image-compressor-that-never-uploads-your-files-4no2 <p>I recently launched <a href="https://imagekittools.com" rel="noopener noreferrer">ImageKitTools</a>, a browser-based image compressor, resizer, and converter built around one rule: your images should stay on your device.</p> <p>A lot of image tools still require uploads for basic tasks. That works, but it also adds friction, privacy concerns, and unnecessary waiting for small workflows like compressing images to 100KB, resizing a few social assets, or converting between JPG, PNG, and WebP.</p> <h2> Why I built it this way </h2> <ul> <li>Privacy: files are processed locally in the browser instead of being uploaded to a server.</li> <li>Speed: local processing feels much faster for everyday image tasks.</li> <li>Simplicity: no account, no watermark, no upload queue.</li> <li>Practicality: batch processing and ZIP download matter more than fancy editing for many users.</li> </ul> <h2> What the tool currently does </h2> <ul> <li>Compress images with practical size targets like 100KB and 200KB</li> <li>Resize images for common workflows</li> <li>Convert between JPG, PNG, and WebP</li> <li>Process multiple files and download the results as a ZIP</li> </ul> <h2> What was harder than expected </h2> <h3> 1. Hitting size targets without destroying quality </h3> <p>"Compress to 100KB" sounds simple until you try to make the result look acceptable across very different images. Some images compress nicely, while others fall apart quickly. The UI has to balance predictable output size with reasonable visual quality.</p> <h3> 2. Keeping the browser responsive </h3> <p>Batch processing is useful, but it is easy to make the browser feel heavy when multiple images are being decoded, transformed, and exported. Managing that workflow carefully matters a lot more than it seems at first.</p> <h3> 3. Making format conversion feel obvious </h3> <p>Users do not want to think about implementation details. They just want to know: what format should I use, what quality will I lose, and what comes out at the end?</p> <h2> What I learned </h2> <p>The biggest lesson is that small utility products become better when they focus on one promise and remove everything that gets in the way. In this case, that promise was: quick image processing, no upload, no watermark.</p> <p>If you want to try it or share feedback, here is the project:</p> <p><a href="https://imagekittools.com" rel="noopener noreferrer">ImageKitTools</a></p> <p>I would especially love feedback on compression quality, batch UX, and which image workflows are still missing.</p> productivity data