Guides

The tools on this site convert, compress, resize and assemble; these guides explain how. Each takes one mechanism the methodology page states in a paragraph — how a format is read from a file's bytes, the pipeline from decode to verified download, when transparency must be flattened, what a quality parameter is and how the compress-to-target search uses it, the decoders behind HEIC and AVIF, what re-encoding strips, resize arithmetic and PDF page geometry — and walks it through on illustrative inputs. Every figure is computed at build time by the engine that processes your files, so the prose cannot describe behaviour the tools do not have. The guides make no quality judgements and recommend no settings; they explain what the engine decides and what it cannot know.

How image formats are detected

A filename is a label; the bytes are the file. This guide follows the detector through the signatures for the 7 formats it recognizes, the ISO-BMFF ftyp parser that tells HEIC from AVIF by brand, and the extension check that reports a mismatch rather than trusting the name. On constructed bytes at build time, the PNG signature returns PNG; a holiday.png beginning FF D8 FF is JPEG claimed as PNG, mismatch yes. It also shows how animation is recognized, so the "first frame only" caveat appears exactly when it applies.

The conversion pipeline

Between a dropped file and a download button sit five stages: detection, planning, decoding with createImageBitmap and imageOrientation: 'from-image', encoding by the browser or a vendored codec, and verification of the produced bytes. The guide shows what the planning module decides for several pairs. At build time the PNG-to-JPG plan flattens transparency at a quality of 0.92; JPG-to-PNG carries none (lossless); logo.png is written as logo.jpg, and photo.jpg re-encoded as JPEG becomes photo-converted.jpg so the download never shadows the original.

Transparency and flattening

The engine's capability table says which targets hold an alpha channel — PNG, WebP, AVIF — and which cannot: JPEG. When a source that may carry transparency meets a target that cannot, the plan sets a flatten flag and the page asks for a background colour first. This guide reads the table row by row and shows the flag on illustrative pairs — WebP to JPG yes, GIF to PNG no — then why a transparent GIF comes back as a transparent PNG, first frame only when animated (yes in the plan's own flag).

Quality parameters and compress-to-target

A quality setting is an encoder parameter on the engine's 0–1 scale, not a percentage of anything measurable. This guide covers the table's defaults — 0.92 for JPEG, 0.85 for WebP — the MozJPEG lane, whose default of 0.75 maps to 75 on that encoder's scale, and the compress-to-target planner, a binary search the page drives one encode at a time. On an invented target of 200,000 bytes it first asks for an encode at 0.95; after an invented result of 310,000 bytes overshoots, it asks for 0.475. No blanket savings figure appears, because none is true for every image.

HEIC and AVIF: decoding and licensing

HEIC and AVIF share a container and part company at the decoder: at build time the same box parser returns HEIC for an ftyp box carrying the heic brand and AVIF for one whose major brand is avif. The engine lists GIF, BMP, HEIC as formats it decodes but never encodes, and AVIF as decoded by the browser alone. In the methodology page's own words, this guide explains why the two HEIC pages load libheif with libde265 — pinned upstream source, self-hosted, a dedicated worker, decode only — why AVIF decoding vendors nothing, and why the site encodes AVIF but never HEIC.

What re-encoding does to metadata

Canvas re-encoding strips all embedded metadata: EXIF, including GPS location, camera model and timestamps; colour-profile tags; and text chunks. That is both a feature and a caveat, and this guide treats it as both — a converted photo cannot leak where it was taken, and a photographer loses copyright fields and ICC profiles, so originals should be kept. It also explains why uprightness survives though the orientation tag does not: rotation is applied during decoding, before anything is discarded.

Resizing math

One pure function sits behind the resizer's three modes. Fit scales by the smaller of box-width over width and box-height over height; exact passes your two numbers through, with an optional lock that derives height from width; percent scales each side linearly. The guide works every mode on illustrative dimensions — a 4032×3024 photo fit into a 1200×1200 box plans 1200×900 — then the rounding rule, the one-pixel floor and the caps: 16,384 pixels per side, 80 megapixels overall, a warning above 50. Enlargement is allowed and flagged, because interpolation adds no detail.

Image to PDF: page math

Image to PDF uses a small writer that assembles PDF 1.4 bytes directly and embeds each JPEG verbatim as a DCTDecode XObject. Page geometry is a pure function, and the guide runs it: in match-image mode an illustrative 1200×1600 image declared at 150 pixels per inch becomes a 576×768 point page; on A4 — 595.28×841.89 points in the engine's table — the same image fits inside half-inch margins at 523.28×697.71 points, offset 36 and 72.09 points from the corner. It also lists what the writer's tests pin.

Where to go from here

The guides explain; the tools do the work. Start from the converter you need — WebP to PNG, HEIC to JPG, AVIF to PNG, the Image Compressor, the Image Resizer or Image to PDF — and each tool page links to the guide behind it. The methodology page is the vetted summary of the whole engine, including how to verify that no file leaves your browser; the about page explains why the site is built this way.

Local processing: every mechanism these guides describe runs inside your own browser tab — files are decoded, converted, and verified entirely in your browser and never transmitted. See the methodology page for how to verify the no-upload claim yourself.