Image compressor / format converter / Base64
Drag in, click to choose, or paste an image to shrink its size, convert between PNG / JPEG / WebP, and produce a Base64 data URL you can embed straight in HTML / CSS. Everything runs locally in your browser — images are never uploaded.
Choose image
Waiting for inputCtrl + V.Original
-
Result
-
Base64 dataURL
Choosing the right format matters more than the quality slider
The first step in compressing an image is not dragging the quality slider — it is choosing the format. JPEG is lossless-free but superbly efficient for photographic continuous tones; at quality 0.7–0.85 the difference is usually invisible. But it has no transparency: a PNG with alpha flattened to JPEG gets a white background (this tool pads white for you so it does not turn an odd black). PNG is lossless and is the natural win for flat screenshots, icons and line art — but storing a photo as PNG can be ten times larger than JPEG. WebP supports both lossy and transparency and is typically 25%–35% smaller than JPEG at the same quality; modern browsers and in-app webviews support it, and if the WebP option is missing from this page your browser has no encoder.
The second big lever is pixel dimensions. The “max side” setting resizes the image proportionally before encoding: dropping a 4000x3000 phone photo to a 1920 long edge is almost invisible on screen yet often halves the size immediately — more effective than any quality number. Web images rarely need more than twice their display width (to cover high-DPI screens); 512 px is already ample for avatars and thumbnails.
A Base64 data URL encodes the image bytes as text so a browser can render them from an HTML src or CSS url() without a second request. The price: base64 inflates every 3 bytes to 4 characters, adding roughly 33% and forgoing HTTP caching, so it suits icons and small decorative images — the “one request saved for a few KB” case. Photos should always stay as real file references; data URLs are also opaque to search engines and crawlers, so they are wrong for images that need to be indexed.
One easily underestimated issue is memory: once a browser decodes an image it uses about width x height x 4 bytes, so an 8000x6000 original can occupy around 190 MB regardless of the file size on disk. Huge panoramas from a phone gallery or tens-of-thousands-of-pixels tall images can stall or crash the tab — resize those with “max side” first. All processing here happens in the browser Canvas, so your screenshots, contracts and ID photos never touch a server.
Refreshing or closing the page clears everything; this tool stores no image at any point.
Frequently asked questions
Are my images uploaded anywhere?
No. The image is read and processed with the Canvas API entirely in your browser, so screenshots, contracts or ID photos never leave your device. Closing or refreshing the page discards everything.
Why did the output end up larger than the original?
The original was probably already heavily optimised. Lower the quality, pick a different format, or reduce the maximum side — a very dense PNG of a photo, for example, shrinks enormously when converted to JPEG or WebP.
Which format should I choose?
Use WebP or JPEG for photos, PNG for screenshots and icons, and if you need transparency do not pick JPEG — it has no alpha channel. WebP is smaller than JPEG at equal quality and is supported by modern browsers and in-app webviews.
When should I use the Base64 output?
Only for small images you want to inline in HTML or CSS. Base64 adds about 33% to the byte size and cannot be cached over HTTP, so large photos should stay as normal file references.