What re-encoding does to metadata

Every converter, compressor and resizer on this site produces its output from decoded pixels, never from the bytes of the file you selected. That single fact decides everything about metadata: what is discarded, what survives, why there is no switch to change it, and what the result row can honestly report afterwards. This guide takes them in the order the pipeline meets them, with the engine's own decisions interpolated wherever a figure appears. For the pipeline itself, see the conversion pipeline; the full index is at the guides page.

What "metadata" means here

The methodology page names three groups: EXIF, which includes GPS location, camera model and timestamps; color-profile tags; and text chunks. These are bytes that sit beside the pixels and describe them. They are not the picture. Three things people often file under metadata are pixel data instead, and the planner treats them accordingly: transparency, which is a per-pixel value that a target either holds or cannot; dimensions, which are measured from the decoded bitmap; and animation, which is a property of the container (a frame count for GIF, a flag or chunk for WebP, a brand for AVIF). Those are decided by the plan, not stripped as a side effect — see transparency and flattening for the alpha case.

Why the pipeline cannot carry it forward

Decoding uses the browser's own codecs through createImageBitmap with imageOrientation: 'from-image'. What comes back is a bitmap: pixel values and two dimensions, nothing else. The bitmap is drawn to a canvas, composited over a background color first when the target cannot hold transparency, and the canvas is handed to an encoder — the browser's PNG, JPEG or WebP encoder, MozJPEG on the Compress JPEG lane, or libavif with aom for AVIF output. Each encoder receives pixels. None is given the original file, so none can copy a segment out of it. The output is a new file whose only inherited content is the pixel values, after orientation and after any flattening, plus the stem of the filename.

The two paths that do not start with createImageBitmap end in the same place. HEIC is decoded by the self-hosted libheif module in a dedicated worker, and what comes back is decoded pixels, wrapped into a bitmap that joins the canvas path like every other format. Image to PDF re-encodes each page as JPEG on a canvas before the PDF writer sees it; the writer then embeds those bytes verbatim as a DCTDecode XObject. "Verbatim" there means the freshly encoded JPEG, not the file you dropped. The only header the writer reads is the new JPEG's own frame header, for width, height and the component count that selects the color space — see image to PDF page math.

This is why no tool here offers a "keep metadata" option. Such a switch would have to read the original's EXIF, color profile and text chunks and write them into the output, and the pipeline contains no code that does either. Nothing in the detection or planning engine parses EXIF at all; the orientation tag is honored only because orientation is applied during decoding, before metadata is discarded: createImageBitmap via imageOrientation: 'from-image' for the formats the browser decodes, while HEIC's self-hosted libheif worker returns decoded pixels that are wrapped into a bitmap before they reach the canvas.

What the detector sees, and what it does not

The first thing any tool does is read a file's leading bytes and match them against the format signatures, as described in how image formats are detected. On a constructed array holding only the JPEG signature FF D8 FF, detectFormat returns JPEG and stops. It reads signatures and ftyp brands, walks the GIF block structure only far enough to find a second image descriptor, and the WebP chunk list only far enough to find the VP8X animation flag or an ANIM chunk — a GIF's extension blocks are skipped by their declared sizes, not parsed. It parses no metadata block, so a metadata block cannot change what a file is detected as, and the detector cannot report which fields a file carried.

The extension check works the same way. A file named holiday.png whose bytes begin with that JPEG signature yields an actual format of JPEG, a claimed format of PNG, and a mismatch flag of yes; the page shows a notice and converts from what the file actually is. Renaming changes neither format nor metadata — the first misreading addressed below. Converted to JPEG, that file would download as holiday.jpg.

Orientation: the one tag whose effect survives

The methodology page puts it precisely: orientation is applied during decoding, before metadata is discarded, so uprightness survives even though the orientation tag does not. For the formats the browser decodes, the mechanism is the imageOrientation: 'from-image' option above. For HEIC, decoded by the self-hosted libheif worker, this guide claims no more than the methodology page does: the worker returns decoded pixels, which are wrapped into a bitmap, and orientation is applied during decoding, before metadata is discarded. In both cases a photo stored sideways with a tag asking for rotation is decoded into a bitmap that is already rotated, so the canvas receives upright pixels and the encoder writes upright pixels. The dimensions the tool reports, plans against and verifies are those of the upright bitmap. The output carries no orientation tag and needs none: the pixels are already stored the way the tag said they should be shown.

Worked plans: what the planner decides for each pair

Which conversions flatten, which take a quality parameter, which drop an animation to its first frame, and what the output is called are decided by a pure planning module. The rows below are that module's answers for illustrative pairs and filenames, computed when this page was built. Notice the column that is missing: there is no metadata decision, because stripping is a consequence of the pipeline, not a setting the plan could hold.

Three details in that table bear on metadata. First, the quality value is on the engine's own scale; the JPEG default maps to encoder 92, and the Compress JPEG lane's MozJPEG default maps to encoder 75. A quality parameter changes how the pixels are encoded; it has no bearing on whether metadata is kept, which is already settled. Second, the HEIC row flattens because a HEIF image can carry an alpha plane and JPEG cannot hold one — a no-op for an opaque photo, and again a pixel decision. Third, when the format does not change, receipt.jpg comes back as receipt-converted.jpg: the suffix exists so the download cannot shadow the original, which is the engine's own nudge toward the advice in the next section.

A feature and a caveat, stated together

The methodology page presents metadata stripping as both, because it is both. The feature: publishing a converted photo cannot leak where it was taken. A photo that passes through HEIC to JPG, PNG to JPG or the Image Compressor on its way to an upload form arrives without GPS coordinates, camera model or capture time, and without any text chunk the original carried. The caveat: photographers lose copyright fields and ICC profiles, so originals should be kept. Nothing on this site edits the file you selected — the download is a new object in your tab's memory — so keeping the original costs nothing more than not deleting it. IMG_4821.HEIC becomes IMG_4821.jpg; the HEIC file stays as it was.

What this guide will not do is tell you how a particular program will render an output whose color-profile tag is gone, or whether a given destination needs the fields that were removed. The tool cannot know either, and it does not guess.

What a size change does and does not tell you

A result row shows the output's true byte count and, where it shows a percent, that percent is computed from the measured before and after counts for your file. Stripped metadata is one contributor to the difference. The encoder, the quality parameter and any resize are others, and the row cannot attribute the change to any one of them. The site publishes no blanket figure for what metadata removal saves, because no figure is true for every file.

To show only how the row phrases its three directions, here is the engine's describeSizeChange on invented counts. From 2,400,000 bytes to 2,292,000 it reads "4.5% smaller". From the same start to 2,712,000 it reads "13% larger — keep your original". An identical count reads "same size". The rounding — one decimal place on the first, a whole number on the second — is the engine's rule, pinned by its tests. The counts are invented and describe nothing but this arithmetic.

How the output is verified, and what verification does not check

Before a download button appears, the produced bytes are sniffed with the same detector applied to inputs, and the blob is re-decoded to confirm its pixel dimensions match the plan. That answers two questions: is the file the format the plan asked for, and does it hold the pixels the plan expected. It does not inspect metadata, for the same reason the detector never reads it: there is nothing in the output to inspect, and no engine on the site has an EXIF parser to inspect it with. If a converted file still appears to carry metadata when you examine it elsewhere, that is a report the contact page wants, because it would contradict the pipeline described here.

Common misreadings

• "Converting is just renaming." Renaming leaves the bytes untouched: a holiday.png that is really JPEG is still JPEG, with every tag intact, and the detector says so. Converting decodes to pixels and encodes a new file, which is what removes the tags.
• "There must be a setting to keep EXIF." There is not, and the absence is structural. The encoders receive canvas pixels; no code path reads the original's metadata.
• "The tool rotated my photo." It applied the rotation the file's own tag requested, then produced an output that needs no tag. The pixels now match what the tag described.
• "Metadata removal is what made the file smaller — or larger." The row measures the whole file and cannot separate removed metadata from the encoder, the quality parameter or a resize.
• "Image to PDF embeds my JPEG untouched." It embeds verbatim the JPEG it just encoded on a canvas. The original's bytes are decoded, not copied.
• "Transparency is metadata." It is pixel data. Whether it survives is a planning decision based on the target's capabilities, shown in the table above.

Related reading

Neighboring guides: the conversion pipeline for the full decode-draw-encode path, how image formats are detected for signature and ftyp parsing, transparency and flattening for the alpha decision, and HEIC and AVIF decoding and licensing for the libheif worker. Tools where the question comes up most: HEIC to JPG, JPG to PNG, Compress JPEG, the Image Resizer and Image to PDF. All eight guides are listed at the guides page.

Frequently asked questions

Local processing: the metadata described in this guide is discarded 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.