Choose a converter.

What every tool on this site shares

FileConverters is 16 tools over one engine. The engine is a set of small, pure, automatically tested functions — a detector that reads bytes, a planner that decides what a conversion will do, a resize calculator, a compression-search planner and a PDF writer — and each tool page is a thin interface over them. Because the planning functions take no file and touch no canvas, this page can show at build time exactly what each tool decides for an illustrative input: every figure below was produced by the same code that will run on your files, and none is typed by hand. The methodology page documents the engine in full; this page is the map.

Files are identified by content, not name

The first thing any tool does with a file is read its leading bytes and compare them with the format signatures: \x89PNG, FF D8 FF for JPEG, RIFF…WEBP, GIF87a/GIF89a, and BM for BMP. HEIC and AVIF share the ISO-BMFF container, so both are identified by parsing the ftyp box — major and compatible brands read from the box structure, bounded by the declared box size, never by substring-searching the file — with explicitly HEVC-coded brands taking precedence over AVIF brands. The table shows the detector's verdict on byte arrays constructed at build time; no file was read.

The filename is then compared against that verdict. An invented holiday.png whose bytes begin FF D8 FF comes back as JPEG claimed as PNG, mismatch true: the row shows a notice and the conversion proceeds from what the file actually is. Animation is recognised before anything is decoded — the VP8X animation flag or ANIM chunks for WebP, image descriptors counted for GIF, the avis brand for AVIF — because canvas and native decoding keep only the first frame, and the "first frame only" caveat must appear exactly when it applies. On constructed bytes: a WebP whose VP8X flags byte carries the animation bit is animated true; the still RIFF header above, false; a GIF with two image descriptors, true; the avis box, true.

One pipeline

Decoding uses the browser's own codecs through createImageBitmap with imageOrientation: 'from-image', so EXIF rotation is applied and phone photos come out upright; a HEIC source is handed to the self-hosted decoder described below instead. The pixels are drawn to a canvas — composited over a background colour first whenever the target cannot represent transparency, which in the engine's capability table is JPEG alone, and the page asks for the colour before converting — and re-encoded by the browser's PNG, JPEG or WebP encoder, or by one of two self-hosted encoders. Which conversions flatten, which take a quality parameter and what the output filename becomes are decided by a pure planning module before a pixel is touched. Canvas re-encoding strips all embedded metadata — EXIF including GPS location, camera model and timestamps, colour-profile tags and text chunks — which is both a feature and a caveat: a converted photo cannot leak where it was taken, and copyright fields and ICC profiles are gone, so originals should be kept. Orientation is applied during decoding, before metadata is discarded, so uprightness survives even though the tag does not.

Every output is verified before download

A download button here means the output has already been checked: the produced bytes are sniffed with the same detector applied to inputs — which catches a browser silently substituting PNG when it cannot encode WebP, reported as an error rather than a mislabeled file — and the blob is re-decoded to confirm its pixel dimensions match the plan. Sizes shown are the output blob's true byte count. Where a row shows a percent change, it is computed from the two measured byte counts for your file and nothing else. To show the wording without implying an expectation: invented counts of 3,150,000 and 410,000 bytes produce "87% smaller", and invented counts of 48,000 and 61,000 produce "27% larger — keep your original". Both are arithmetic on made-up numbers.

Local processing, enforced by architecture

The site is static files: there is no server application and no upload endpoint to receive a file. The Content-Security-Policy header sets connect-src 'self', so the browser itself refuses to let scripts on any page send data to another origin, and the vendored decoder and encoders are fetched from this origin and run in bounded workers in your tab. Open DevTools → Network while converting and you will see nothing but the page's own static assets; downloads are object URLs pointing at memory in your own tab.

The check is one you can make rather than take on trust, and the methodology page lists the steps: open the Network tab before adding a file, convert, and look for any request that is not one of the page's own static assets; then read the response headers for the Content-Security-Policy line and its connect-src directive. Because the enforcement belongs to the browser and to the architecture rather than to a sentence in a privacy policy, it holds the same way on every page of the site, including the pages that fetch the self-hosted decoder and encoders: those modules come from this origin, run in workers inside your tab, and have nowhere else to send anything.

The tools, by family

The sidebar lists every tool; this directory says what each one's plan decides, in the engine's own terms, on an illustrative filename. The site decodes PNG, JPEG, WebP, GIF, BMP, HEIC, AVIF; it produces PNG, JPEG, WebP, AVIF, and PDF, and its capability table marks PNG as the lossless target. GIF, BMP, HEIC are sources only — the site decodes them (GIF and BMP by the browser, HEIC by the self-hosted libheif module) but has no encoder for them — and HEIC is never a target, for the licensing reason stated below. AVIF is decoded by the browser's own codec with nothing vendored. Quality figures are the capability table's defaults on the engine's 0–1 scale, stated here rather than recommended; every page that takes a quality parameter exposes it as a control.

Converters between PNG, JPEG and WebP

• WebP to PNG: a lossless target, so the plan's quality is none (lossless), keeps transparency (flatten no) and sets the first-frame caveat to yes because WebP can be animated; banner.webp downloads as banner.png.
• WebP to JPG: JPEG holds no alpha, so flatten is yes over a colour you choose, at quality 0.92; first-frame caveat yes; banner.webp becomes banner.jpg.
• PNG to JPG: flatten yes, quality 0.92, caveat no — PNG is not animatable; logo.png becomes logo.jpg.
• JPG to PNG: nothing to flatten (no), quality none (lossless); the decoded pixels are repackaged exactly, which protects against further loss and never recovers what JPEG already discarded; holiday.jpg becomes holiday.png.
• PNG to WebP: WebP keeps alpha (flatten no) and the capability table marks WebP as lossy, so the plan carries quality 0.85; logo.png becomes logo.webp.
• JPG to WebP: quality 0.85, flatten no, caveat no; holiday.jpg becomes holiday.webp.

HEIC lanes

• HEIC to JPG: decoded by the self-hosted libheif in a dedicated worker; the plan flattens (yes) because HEIF images can carry an alpha auxiliary plane — a no-op for an opaque photo — at quality 0.92; IMG_4821.heic becomes IMG_4821.jpg.
• HEIC to PNG: the same decoder into a lossless target — quality none (lossless), flatten no, so any alpha plane survives; first-frame caveat no, because HEIC is not among the containers the planner treats as animatable, so no frame can be lost on this lane. Decoding is the whole of the third-party involvement: once libheif has returned pixels, the canvas draw, the PNG encode, the metadata stripping and the output check are the same steps every other lane runs; IMG_4821.heic becomes IMG_4821.png.

AVIF lanes

• JPG to AVIF: encoded by the self-hosted libavif + aom module at engine quality 0.5, which the lane maps to encoder 50 on its 0–100 scale, aom speed preset 8; the lane offers no target-size search (false), and the page says why; holiday.jpg becomes holiday.avif.
• PNG to AVIF: the same lane with alpha kept (flatten no), at the same engine quality 0.5 and encoder 50; first-frame caveat no, since PNG is not animatable. The lane's target-size search is false here too, so this page offers the quality control only, and the row reports the measured byte count of whatever the encoder produced rather than a figure chosen in advance; logo.png becomes logo.avif.
• AVIF to JPG: decoded natively, with a runtime feature probe; flatten yes, quality 0.92, first-frame caveat yes for the avis image-sequence brand; hero.avif becomes hero.jpg.
• AVIF to PNG: decoded natively into a lossless target — quality none (lossless), flatten no, caveat yes; hero.avif becomes hero.png.

Compressors and the resizer

• Image Compressor: a quality slider — the table's defaults are 0.92 for JPEG and 0.85 for WebP — or a target in kilobytes solved by measurement: the planner's first step on an empty attempt list is to encode at quality 0.95, and it then brackets between the highest quality known to fit and the lowest known to overshoot, converging within eight encodes as the methodology page states. When even minimum quality overshoots, the step is unreachable and the tool reports the smallest achievable size — on an illustrative attempt list, 260,000 bytes at quality 0.05 against a 200,000-byte target — instead of claiming success. PNG inputs are converted to a lossy format and labelled as such. A same-format re-encode keeps the stem, and this tool passes its own suffix, -compressed, to the naming function so the download cannot shadow the original: holiday.jpg becomes holiday-compressed.jpg.
• Compress JPEG: the MozJPEG lane, any decodable source in and JPEG out, at the lane's default of 0.75 on the engine scale — encoder 75 — with progressive scan order on by default and target-size search available; the row measures the result rather than promising one.
• Image Resizer: fit, exact or percent. Fit scales by the smaller of box-width over width and box-height over height, so an invented 4032×3024 photo fit into 1200×1200 plans 1200×900; 25% of the same photo plans 1008×756. Outputs are capped at 16,384 pixels per side and 80 megapixels, with a warning above 50 megapixels; enlargement is permitted but flagged with the engine's own wording — an 800×600 image fit into 1600×1600 plans 1600×1200 and carries "Enlarging beyond the original size cannot add detail — the result will be softer than the source."

Documents

• Image to PDF: a ~200-line PDF 1.4 writer with no library — a catalog, a page tree, and per image a page object, a content stream and the JPEG bytes embedded verbatim as a DCTDecode XObject, with grayscale and CMYK colour spaces read from the JPEG's own frame header. Page geometry is a pure function: the 1200×900 image above at an illustrative 96 DPI in "match image" mode becomes a 900×675 pt page; on A4 (595.28×841.89 pt) inside the writer's default margin — read back from the writer itself as 36 pt, 0.5 inch, the half inch the methodology page states — it is drawn 523.28×392.46 pt at offset 36, 224.72; on Letter (612×792 pt) it is drawn 540×405 pt at offset 36, 193.5. Tests assert the header, object count, cross-reference offsets, EOF marker and the byte-for-byte JPEG round-trip.

The 12 conversion plans at a glance

One row per converter, every cell the planning module's output at build time for the illustrative filename named. "Flatten" means the page will ask for a background colour and composite over it; "first frame" means the source container can be animated and the row will say only the first frame was converted when it is.

Decoders and encoders, with their licences

Every tool decodes with the browser's own codecs except for HEIC sources, because no browser ships a HEIC decoder: the two HEIC pages load libheif — © struktur AG and contributors, licensed LGPL-3.0 — compiled to WebAssembly from pinned upstream source together with its libde265 HEVC decoder from the same upstream family, also LGPL. The codec source is compiled without source modifications, self-hosted from this site's own origin under /vendor/libheif/, and loaded at runtime as a separately replaceable module in a dedicated worker, never compiled into the site's own JavaScript; the full license text ships alongside at /vendor/libheif/LICENSE.txt. The build is decode only. Why a third-party decoder at all? Because "convert my iPhone photo" is the request, and the alternative — uploading a camera roll to someone's server — is what this site exists to avoid.

Two vendored encoder lanes, on three tool pages, go beyond the browser's built-in encoders under the same arrangement: open-source codecs compiled from pinned upstream source, served from this origin as separately replaceable files, fetched lazily only when a file is actually dropped, and run in bounded workers. Compress JPEG encodes with MozJPEG, Mozilla's JPEG encoder built on libjpeg-turbo — this site includes the libjpeg-turbo software, covered by the IJG, Modified (3-clause) BSD, and zlib licenses — through a hardened browser binding derived from Google's Squoosh/jSquash wrapper under Apache-2.0; license texts ship at /vendor/mozjpeg/LICENSE.txt and /vendor/mozjpeg/LICENSE-codec.txt. JPG to AVIF and PNG to AVIF encode with libavif (© Joe Drago and contributors) driving the aom AV1 encoder (© Alliance for Open Media), both BSD-2-Clause, under the royalty-free Alliance for Open Media Patent License, through the same kind of Apache-2.0 binding; license and patent-grant texts ship at /vendor/avif/LICENSE.txt, /vendor/avif/LICENSE-libavif.txt, /vendor/avif/LICENSE-aom.txt, and /vendor/avif/PATENTS-aom.txt. Every vendored file's exact size and SHA-256 is pinned by automated tests, and every codec build uses immutable upstream commits, so served bytes cannot drift silently.

AVIF decoding deliberately vendors nothing: current Chrome and Edge, Firefox 93+, and Safari 16.4+ decode AVIF natively, so AVIF to JPG and AVIF to PNG use the browser's own codec with a runtime feature probe and a plain-language notice when a browser cannot. And the site encodes AVIF but never HEIC: the two are structurally siblings — the same HEIF container around a modern video codec — but HEIC's HEVC codec is covered by commercial patent pools, which is why browsers do not ship HEVC encoders and why the libheif build here is decode-only, while AVIF's AV1 codec was developed by the Alliance for Open Media to be royalty-free under an explicit patent grant. Conversions here go from HEIC and to AVIF, never the reverse.

What this site refuses to claim

• No blanket compression percentages. No percentage is true for every image, so none is published; the only one you will see is the arithmetic on your file's two measured byte counts, and a larger result says "keep your original" in the same breath.
• No quality judgements. Verification checks format and dimensions; it does not look at the picture. Defaults are stated as the engine's defaults, never recommended as settings, and no page says what a result will look like.
• No "enhancement". Enlargement spreads the same information across more pixels; the resizer performs it when asked and attaches the engine's warning to the row.
• No pretending. An unreachable target is reported as the smallest achievable size; a PNG cannot honestly be "PNG-compressed" on a canvas, so it is converted to a lossy format and labelled; a browser that writes a format it was not asked for is reported as an error, not handed over as a mislabeled file.
• Flags, not verdicts. A plan says what will happen — flattening, a quality parameter, a first-frame caveat, a filename — and the row says what did happen. Whether the result suits its destination is a judgement the tool cannot make, and does not. Verification answers two questions — is the output the format the plan named, and are its dimensions the ones the plan computed — and no third: it does not compare pixels with the source, does not score the result, and does not know what the file is for. The figures on this page are of the same kind, what the planner returns for an illustrative input, read at build time, never an expectation about yours.

Start here: the guides

Each tool page shows what its plan decides; the guides work the mechanism behind every family of decisions on the same kind of illustrative inputs, with every figure computed by the engine at build time. Read them in this order or jump to the one your question names.

• How image formats are detected — signatures, ftyp brands, extension mismatch and animation detection, demonstrated on constructed byte arrays.
• The conversion pipeline — createImageBitmap, orientation, the canvas, the plan for several pairs, and output verification.
• Transparency and flattening — the capability table, which targets drop alpha, and the background-colour prompt.
• Quality parameters and compress-to-target — the quality scales, the MozJPEG lane, and the binary-search planner on an illustrative attempt list.
• HEIC and AVIF: decoding and licensing — the licensed decoder and encoder facts, why AVIF out and never HEIC, and the vendored-file pinning.
• What re-encoding does to metadata — what a canvas re-encode strips, why orientation survives, and why originals should be kept.
• Resizing math — fit, exact and percent on illustrative dimensions, the rounding rule, the 1-pixel floor and the output caps.
• Image to PDF: page math — match-image, A4 and Letter geometry, DCTDecode embedding, and what the tests pin.

The guides index lists them all; the methodology page is the single vetted account they expand on, and about says who publishes the site and why.

Frequently asked questions

Local processing: files are decoded, converted, and verified entirely in your browser and never transmitted. How that is enforced — and how to check it yourself — is on the methodology page.