Three jobs account for almost every visit here: making a file smaller, making it the right size, and changing its format. They sound like one job and are not. Compression changes how much detail the encoder keeps, resizing changes how many pixels exist, conversion changes the container around them.
Which tool should I use?
- Image Compressor
- The right choice when the dimensions are already correct and only the byte count is a problem. One quality slider, defaulting to 80, governs how much detail survives encoding; width and height are untouched. For PNG the library performs colour quantisation rather than JPEG-style quality reduction, so photographic PNGs can return with visible banding — and an already-optimised file can even grow, in which case the reduction figure turns negative.
- Image Resizer
- Use this when a specific width or height is the requirement: an upload capped at 2000 px, a fixed layout column, or a 4000 px phone photo nobody needs at full scale. Aspect ratio is locked by default, so editing one field computes the other. There is no quality control, and JPEGs are re-encoded at the browser's default, which means a resize also recompresses the picture once.
- Image Format Converter
- For changing the format while leaving pixel dimensions alone — JPEG, PNG or WebP. Check for a transparent background before converting to JPEG: that format has no alpha channel, so a cut-out logo lands on a black rectangle. The quality slider disappears for PNG, because the format takes no quality parameter.
- Image to Base64
- The one tool here that never touches a pixel. It reads the file exactly as it is into a data URI and hands back four copyable forms — full URI, bare payload, an
<img>tag and a CSSbackground-imagerule. Encoding inflates the payload by about a third, so shrink the image first.
Shared limitations
- All four handle one image at a time. Dropping several picks up the first only, with a 10 MB ceiling per file.
- Anything that goes through a canvas redraw — compression, resizing, conversion — comes out without EXIF. Capture time, GPS coordinates and camera model are gone from the output; Image to Base64 is the only one that leaves them intact.
- Animated GIF and WebP lose everything after the first frame in the first three tools, and vector formats such as SVG become raster once redrawn. Neither is rejected on drop, and the download may carry an extension that no longer matches its contents.
- Images are read on your own device with
FileReaderand<canvas>; there is no upload step. The compressor needs a library that runs inside a Web Worker, and that file is served from this site rather than fetched from a third-party CDN. The page does still carry advertising resources of its own.
FAQ
Why did compression make my file bigger?
Usually because it was already optimised. Compressing means encoding the image again, and if the original went through a stronger encoder such as mozjpeg or pngquant, the second pass will not beat it. Keep the original in that case — the tool will not silently choose the smaller of the two for you.
Should I compress first or resize first?
Resize first. Byte count is driven mostly by pixel count, so a 4000×3000 photo squeezed to quality 50 is still larger, and visibly worse, than the same photo scaled to 1200 px wide and then compressed. Every redraw costs a little detail, so fewer steps is better.