Image Converter

Every file you drop is decoded to raw pixels in this tab, scaled if you asked for that, and handed to a real encoder compiled to WebAssembly — MozJPEG for JPG, libwebp for WebP, libaom for AVIF and OxiPNG for PNG. The SVG target is the exception, because it has no encoder at all: it writes outlines rather than pixels.

photo.png → photo.avif — the same pixels through libaom, not through canvas.toBlob

These are the same encoders Squoosh runs, and they are why the output is not simply what the browser would have written. Nothing is uploaded: there is no server in this flow at all, the codecs are downloaded once on demand, and everything after that happens on your machine — so a picture converted here never leaves the tab it was dropped into.

Four of the seven targets name a single encoder. Two build an icon file, which is a container rather than a format — PNG all the way down, arranged so a browser or an operating system can pick the size it wants. The seventh holds no pixels at all: it traces the picture into outlines and writes them as SVG.

SVG goes both ways here, and the two directions are not mirror images of each other. Reading one is exact: the file describes shapes, the browser draws them at whatever size this tool asks for, and a 24-pixel icon file makes a sharp 512-pixel favicon because there was never a 24-pixel grid to enlarge. Writing one is an approximation, because the picture is a grid and the shapes have to be inferred from it.

Dropping an SVG in is the reliable half. The Longest edge control changes meaning for it: for a raster source it is a cap that never enlarges, and for a vector source it is the size to draw at. Leave it on Keep original size and the file's own width and height are used; a file that declares neither is drawn at 512. Pick an icon target and the drawing is rendered at the largest square that target writes, so the big icon is a fresh rendering rather than an enlargement of a small one. One thing the URL field cannot do is fetch an SVG: the import path this site shares between its image tools accepts only the formats a codec decodes, so an SVG has to be dropped in or picked from disk.

An SVG is handed to the browser as an image and never as markup on this page, and an image is rendered in what the specification calls secure static mode: no script runs, no external file is fetched, nothing is interactive. That is a guarantee from the browser rather than a filter written here. It has one visible consequence — an SVG that pulls in a bitmap or a webfont over the network loses it, because fetching that file is exactly what the mode blocks.

Converting to SVG traces. The colours are cut down to the count you picked by median cut, regions too small for the quality you set are folded into whichever neighbour they share the most border with, and the boundary of every region that survives is followed along the pixel grid and then straightened. Nothing is smoothed into curves: the outlines are polygons whose corners sit on grid vertices, which is why every coordinate in the file is a whole number.

That makes it very good at one job and bad at the rest. A logo, an icon, a stencil or a screenshot of flat interface comes out as a few dozen paths, usually smaller than the PNG, and scales forever. A photograph comes out as thousands of paths, larger than the JPEG, looking like a bad watercolour. When a trace comes out wrong the fix is almost always fewer colours rather than more.

Asking for SVG with an SVG already in hand copies the file through untouched, bytes and all. Rasterising a vector in order to trace it back into one would replace exact curves with a polygon approximation of a rendering of them — so the row says it was copied rather than pretending work was done.

Controls that cannot affect the target you picked are disabled rather than left live and quietly ignored, and the hint underneath each one says why it went grey.

The pack is not a matter of taste. Every file in it exists because some specific client asks for it: favicon.ico at 16, 32 and 48 is what a browser requests from your site root whether or not anything links to it, and what Windows reads for a pinned shortcut; favicon-96x96.png covers a high-DPI tab; apple-touch-icon.png at 180 is what iOS puts on the home screen; and the 192 and 512 PNGs are the pair an install prompt looks for through the web app manifest.

The .ico holds PNGs rather than the older headerless bitmap-plus-mask form. Every browser reads PNG-compressed entries, and so has Windows since Vista — while a 48×48 bitmap entry costs nine kilobytes where the PNG costs a few hundred bytes. If you are targeting Windows XP, this is the one thing here that will not work for you.

The site.webmanifest takes its name and short_name from your filename, because the alternatives were to invent a site name or to add a text box for one. Edit it — it is two fields at the top of the file. The manifest deliberately leaves out theme_color and background_color: this tool does not know your site's colours, and a guessed #ffffff is a wrong answer wearing the clothes of a considered one.

The manifest icons declare purpose "any", never "maskable". A maskable icon promises that its content stays inside a safe zone the launcher may crop to a circle; these icons are scaled to fill the square, so claiming maskable would cost the edges of your logo on Android and nowhere else. If you want maskable icons, add padding to your source picture first and declare it yourself.

head.html in the pack holds the same four link tags shown above the queue, and assumes the files sit at your site root. Move them into a subfolder and the href values need the same move.

An icon is square and most pictures are not, so something has to give. This tool scales the picture to fit inside the square with its proportions intact and fills what is left with the background — it never stretches. Stretching is immediately visible on a logo, and a logo is what people convert to icons.

Every size is scaled from the source pixels, not from the size above it. Chaining a 512 down to a 256, then a 128, then a 64, then a 16 compounds the resampling error four times over, and a 16×16 icon has no pixels to spare.

Asking for a size larger than the source is allowed, and the row says so. A 512 icon made from a 200-pixel logo is a genuinely enlarged picture and will look soft; the tool would rather tell you than quietly drop the size or refuse the file.

PNG, WebP, AVIF and both icon targets carry an alpha channel. JPG does not — it has no way to record it — so the Background control drops its transparent entry the moment you pick JPG, rather than accepting a setting it would then have to ignore.

Flattening composites the picture over a solid colour: each pixel becomes source × alpha + background × (1 − alpha). It is not the same as deleting the alpha channel. An encoder handed transparent pixels with no instruction keeps whatever colour happened to sit underneath, which is usually black — and a logo that turns into a black rectangle is the single most common surprise in image conversion.

For an icon, the padding around a non-square picture follows the same setting. Keep transparent and a wide logo sits on nothing, which is what a favicon usually wants; choose a colour and it sits on that colour, edge to edge, with no seam between the picture and its margin.

A picture with no transparency at all is left alone whatever you choose here, so the setting costs nothing to leave where it is.

Quality is not a percentage of anything. It is a knob on the quantiser, and the same number means different things to different encoders — MozJPEG at 80 and libaom at 80 are not the same trade.

100 is the default here, because converting is a request for a different format, not a smaller file — the picture is expected to survive the trip, including when the source was already lossy and this re-encode compounds with it. Lower it when the bytes matter more than the last bit of detail.

Below about 60 the artefacts stop being subtle: blocking on flat areas in JPG, smearing on fine detail in WebP and AVIF. Above about 92 you are mostly spending bytes on noise. If a specific gradient bands, raise the quality rather than switching format — banding is a quantiser problem, and every encoder here has one.

Decoding a picture to pixels drops everything that was not pixels. EXIF goes, which includes the camera model, the exposure settings and any GPS coordinates. The embedded colour profile goes too, so a photograph in Display P3 or Adobe RGB comes back as plain sRGB and its most saturated colours will shift.

The one metadata field that is honoured rather than dropped is orientation. A phone writes the picture in the sensor's own rotation and records which way up it was, so an encoder that drops the tag without applying it turns every portrait photograph sideways. This tool applies it first, then discards it.

Losing EXIF is often the point — it is the simplest way to strip GPS coordinates out of a picture before publishing it. But if you need the metadata, keep the original: nothing here can put it back.

Forty files at a time, twenty-five megabytes each. Both numbers are about memory in one browser tab rather than about bandwidth, because nothing here is uploaded.

There is also a forty-megapixel ceiling, checked after decoding rather than from the file size, because the two are barely related — a two-megabyte PNG can hold a hundred megapixels, and four bytes per pixel is what actually has to fit.

The favicon pack does seven encodes per picture where a raster target does one, so a batch of packs takes appreciably longer than the same batch converted to WebP. The progress count is per file, not per encode, so a pack row sits on one number for a while.

A trace runs on a grid capped at 1000 pixels on its longest edge, whatever size the picture arrived at. That is not the size control in disguise — the output is a vector and scales to any size regardless. It is that tracing costs work per region, and a larger grid does not find bigger shapes, only more specks of noise to draw an outline around.

Codecs load only when they are used. If you never pick AVIF, libaom is never fetched — so the first conversion into a format you have not used yet takes a moment longer while its encoder arrives. Files are then worked through one at a time rather than all at once: a decoded picture costs four bytes per pixel whatever the file size, so converting twenty at the same time is how a tab runs out of memory halfway through. One at a time is also the only way the progress count can be honest.

No picture you drop here is uploaded, and no server is involved in the conversion. The codecs are WebAssembly modules fetched once from this site and then run in your tab.

Nothing is stored either. Close the page and the queue, the previews and every converted file are gone with it — so download what you want before you leave.

That also means this works offline once the page and the codec for your chosen format have loaded.