The latest articles on DEV Community by Jack Liu (@cser700). https://dev.to/cser700 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4030392%2F8f1b3c9f-7a5f-4374-a752-66a7a81bfb6e.png https://dev.to/cser700 en Jack Liu Wed, 15 Jul 2026 12:21:54 +0000 https://dev.to/cser700/why-i-prefer-browser-local-image-resizing-for-small-files-1178 https://dev.to/cser700/why-i-prefer-browser-local-image-resizing-for-small-files-1178 <p>When a form asks for an image under 100KB, the obvious reaction is to search for an online compressor and upload the file. That works, but it also adds an unnecessary privacy decision: does this image need to leave the device at all?</p> <h2> A simpler workflow </h2> <p>For ID photos, screenshots, receipts, and other personal images, I prefer tools that do the work locally in the browser. The browser reads the file, resizes or recompresses it, and gives the result back without sending the original to a remote server.</p> <p>My practical process is:</p> <ol> <li>Start with the original JPG, PNG, or WebP.</li> <li>Set the required maximum size rather than guessing a quality percentage.</li> <li>Keep the aspect ratio unless the destination specifies exact dimensions.</li> <li>Preview the result at normal size, especially around text and faces.</li> <li>Save the new file under a different name so the original remains untouched.</li> </ol> <h2> Why target size matters </h2> <p>A generic “compress” button may produce a smaller file, but not necessarily one that meets a strict upload limit. A target-size workflow is more useful because it can adjust dimensions and quality together. For many document portals, a visually clean 80–95KB result is safer than a 99.9KB result that may fail after metadata is added.</p> <p>PNG is excellent for flat graphics and screenshots, while JPG is often better for photos. WebP can be efficient, but some older upload forms still accept only JPG or PNG. The destination's rules should decide the output format.</p> <h2> The tool I use </h2> <p>I built <a href="https://resizeimage.site/" rel="noopener noreferrer">Resize Image</a> around this browser-local approach. It is useful when I need a quick image under a specific size and do not want the original uploaded as part of the resizing process. The link is included for context and disclosure: I am the maker.</p> <p>Local processing does not remove every privacy concern—you should still review the downloaded result and the site where you eventually upload it—but it reduces one unnecessary transfer.</p> <p>The larger lesson is simple: for lightweight image work, the browser is already capable enough. A small, focused local tool can be faster, more predictable, and easier to trust than sending every file through a remote processing queue.</p> webdev productivity privacy