How this converter actually works
Which decoder handles which format, what happens to your metadata, and where the real limits are. Written from the code, not from the marketing copy.
The short version
ImageConvert.tools decodes your file into a pixel buffer inside your browser, optionally resizes it, then encodes that buffer into the format you asked for. Nothing is sent anywhere. There is no server involved in a conversion because there is no server-side conversion code to involve: the entire pipeline is JavaScript and WebAssembly served from this domain and executed on your device. That is also why there are no limits on file size or on how many files you convert. It costs us nothing, because the work is not ours.
Decoding: getting your file into pixels
Most of the work is done by the decoders your browser already ships. A PNG, JPG, JFIF, WebP, AVIF, GIF, BMP or ICO is handed straight to the browser's own image decoder and drawn onto a 2D canvas. Two formats browsers will not decode get dedicated libraries:
| Input format | Decoder | Where it runs |
|---|---|---|
| PNG, JPG, JFIF, WebP, AVIF, GIF, BMP, ICO | The browser's built-in image decoder | Native, on your device |
| HEIC and HEIF | heic2any, which wraps libheif compiled to WebAssembly | WebAssembly, on your device |
| TIFF | UTIF, a pure JavaScript TIFF decoder | JavaScript, on your device |
| SVG | The browser's SVG renderer, after explicit width and height are injected if the file only carries a viewBox | Native, on your device |
The SVG step deserves a note, because it is the one place a converter can silently produce the wrong thing. An SVG with only a viewBox and no explicit dimensions has no intrinsic size, and a browser asked to rasterise it will guess. Rather than guess, the width and height are read out of the viewBox and written into the file before it is drawn, so the output matches the drawing's own coordinate space.
Encoding: getting pixels back into a file
| Output format | Encoder | Notes |
|---|---|---|
| PNG | canvas.toBlob, the browser's own encoder | Lossless. There is no quality setting, because PNG does not have one. |
| JPG | canvas.toBlob | Lossy. The quality slider maps straight onto the browser's JPEG quality. |
| WebP | canvas.toBlob | Lossy in this pipeline, at the quality you choose. |
| AVIF | libavif compiled to WebAssembly, 3.3 MB, served from this domain | Loaded on the first AVIF export only, then cached by your browser. The output bytes are checked for a real AVIF file signature before you get them. |
| BMP | Written here, byte by byte | Uncompressed 24 bit, bottom-up rows, 72 DPI resolution field. The plain BITMAPINFOHEADER form that legacy Windows tooling reads without complaint. |
| ICO | A PNG wrapped in an ICO header, written here | One image per file. Anything larger than 256 x 256 is scaled down first, because that is the format's own ceiling. |
| GIF | gifenc | A single frame, quantised to a 256 colour palette. GIF cannot hold more colours than that. |
| TIFF | UTIF | Lossless, and considerably larger than the input in almost every case. |
jsPDF | One image per page, page sized to the image's pixel dimensions, image embedded as JPEG at quality 0.92. |
The default quality when you do not touch the slider is 0.9, and the slider is clamped between 0.1 and 1 so a stray value cannot produce an unusable file.
What happens to your metadata
This is the part almost no converter documents, and it is the part people get burned by. Because every conversion here goes through a pixel buffer, the pixels are all that survives. Concretely:
| What | What happens |
|---|---|
| EXIF (camera, date, exposure) | Removed. It is not carried across into the output file. |
| GPS location | Removed, along with the rest of the EXIF block. If stripping location data is why you are here, this conversion does it. |
| Orientation flag | Applied, then dropped. Browsers rotate the image while decoding, so the output is upright without needing the flag. |
| ICC colour profile | Not carried across. The canvas works in sRGB, so a wide gamut original is converted to sRGB on the way through. For photographs destined for the web this is usually what you want; for print work it is not. |
| Transparency | Preserved into PNG, WebP, AVIF, GIF, TIFF and ICO. Flattened onto solid white for JPG, BMP and PDF, because none of those can store an alpha channel. |
| Animation frames | Not preserved. An animated GIF or WebP goes in and a single still frame comes out. |
| Multi-page TIFF | Only the first page is decoded. |
What conversion cannot do
A conversion changes the container and the compression. It does not improve the picture, and any converter that suggests otherwise is selling something. Two consequences worth being explicit about:
- Lossy to lossless does not restore anything. Converting a JPG to PNG gives you a file that will not lose any more detail from that point on. The detail the JPEG encoder already discarded is gone, and the PNG will usually be several times larger for a picture that looks identical.
- Lossy to lossy compresses twice. Converting a JPG to WebP, or an AVIF to JPG, decodes one lossy encode and performs another on the result. At a high quality setting the difference is hard to see; at a low one it compounds. If you have the original, convert from that rather than from a copy.
Video and audio, and the 30 MB question
Video conversion runs on FFmpeg compiled to WebAssembly. The core is a single ffmpeg-core.wasm file of 32,129,114 bytes, about 30 MB, and it is served from this domain rather than from a public CDN. That choice costs bandwidth and buys something specific: no third party gets to observe that you are converting a video, and the site's own network policy can stay strict enough to be checkable.
The engine is fetched on your first video conversion, never on page load, and never on any page other than the three video tools. Your browser caches it afterwards, which is why the first conversion is slow and the rest are not. On a phone, expect the download to be the slowest part of the whole operation the first time.
The honest limit here is memory rather than time. Everything is decoded in your device's RAM, so a long or high resolution video can exhaust the tab's memory and fail. There is no fixed threshold to quote, because it depends on your device, your browser and what else is open. If a conversion fails on a phone, the same file usually converts on a laptop.
Formats we read but cannot write
HEIC, SVG and JFIF are input only, and the reasons are different in each case.
- HEIC. HEIC stores HEVC-encoded images. No browser exposes an HEVC image encoder to a web page, and HEVC is patent encumbered. Decoding is possible with a WebAssembly build; encoding is not something this site can offer honestly.
- SVG. Converting pixels into vector shapes is tracing, not conversion. It is a lossy, subjective process with no single right answer, and the output would not be an SVG of your image so much as an approximation of it.
- JFIF. JFIF is JPEG data with a different extension. Writing a JPG produces the same bytes under a name more software recognises, so JPG is what comes out.
Why this can be verified rather than believed
"Your files never leave your browser" is a claim every converter makes, including the ones that upload everything. The difference here is that you can check it in under a minute, and the three ways to check are written out: watch the network tab during a conversion, or simply disconnect from the internet and convert anyway.
Built by FusionStudios
ImageConvert.tools is built and maintained by FusionStudios, a web studio in the Netherlands. We build fast, private, client-side web tools, and this one exists partly because it is genuinely useful and partly because it is the clearest demonstration we have of what a browser can do without a backend. If you need something built along these lines, get in touch.