What file conversion actually does (and what you lose).
"Convert to PDF" sounds like translation — same content, different language. It's closer to photocopying: the file is decoded into raw form and re-encoded from scratch, and what survives the trip depends entirely on what the two formats can each hold. Here's the pipeline every converter runs, the four things that get lost, and why converting back never un-loses them.
Every converter — the good ones, the sketchy upload sites, the one on this site — does the same two-step dance. There is no such thing as directly "turning" a JPEG into a PDF; formats are too different internally for that. Instead:
The decode–re-encode pipeline.
source file ──decode──▶ raw form ──re-encode──▶ target file
(HEIC) (a grid of pixels) (JPEG)
Decode: the source is unpacked into a raw intermediate — for images, an uncompressed grid of pixel colors; for documents, laid-out pages. Everything the source format encoded cleverly (compression, layers, metadata) is either expanded into the raw form or set aside. Re-encode: the raw form is compressed and packaged using the target format's rules, as if the file were being created for the first time.
That "as if for the first time" is the important part. The target file doesn't remember what it came from — and anything the raw intermediate didn't carry, or the target format can't express, is simply gone. Which brings us to the four categories of loss.
Loss #1: quality, again and again.
If the target uses lossy compression (JPEG, HEIC, lossy WebP), re-encoding discards detail — that's what lossy means, and the image compression guide covers the mechanics. The conversion-specific trap is generation loss: each lossy re-encode compounds on the last. HEIC → JPEG once is usually invisible; a file that's been through five casual convert–share–convert cycles picks up smudging and block artifacts around edges, like a photocopy of a photocopy. Every conversion between lossy formats is a generation. Convert once from the original, keep the original, and generations stop mattering.
Loss #2: what the target can't hold.
Formats aren't interchangeable containers — each has a feature list, and conversion silently truncates to the intersection:
| You had | Converting to | What happens |
|---|---|---|
| PNG transparency | JPEG | No alpha channel — transparent areas become a flat color (usually white or black) |
| Animated GIF/WebP | PNG, JPEG | One frame survives; the animation doesn't |
| HEIC live photo / depth data | JPEG | The still image survives; the motion clip and depth maps don't travel |
| Wide-gamut / HDR color | sRGB-only pipeline | Colors clamp to the smaller gamut; the punchiest reds and greens dull |
| Selectable PDF text | Image (PNG/JPEG) | Text becomes pixels — no more selecting, searching, or accessibility |
None of these announce themselves. The converter doesn't error — it produces a perfectly valid file that quietly holds less than the one you gave it. The fix is direction-of-travel awareness: know what the source has that the target can't, before converting.
Loss #3: metadata (sometimes a feature).
Photos carry EXIF baggage: timestamps, camera model, edit history, and — on phone photos — GPS coordinates of where you stood. Conversion pipelines vary from "copy everything across" to "strip it all," and most tools don't say which they do. Both behaviors are sometimes right: stripped metadata breaks photo-library timelines and loses the orientation flag (hello, sideways image), while kept metadata means the photo you posted publicly still knows your home address. The only good version of this is the explicit one — a converter that tells you what it keeps. (A hex look at the file's actual bytes settles what survived, if you're ever unsure.)
Loss #4: rasterization is a one-way door.
Some content isn't pixels at all. SVG stores shapes as math; PDF text is characters plus fonts plus positions. Convert either to a pixel format and it gets rasterized — the math is evaluated once, at one resolution, and the result is a picture. It looks identical at that size and falls apart when zoomed, and no tool can climb back up: recovering shapes from pixels (vector tracing) or text from pixels (OCR) is approximate reconstruction, not undo. The rule: keep the vector/text original forever; export pixels as needed, per size, like disposable prints from a negative.
Why converting back doesn't undo it.
The tempting mental model — "I'll just convert it back if it looks worse" — fails because the pipeline has no memory. JPEG → PNG → JPEG doesn't restore anything: the PNG faithfully preserved the already-damaged pixels (PNG is lossless — lossless at preserving what it was given), and the second JPEG pass adds a fresh generation of loss on top. Same for a flattened transparency or a rasterized SVG: the information isn't hiding in the new file, it's absent from it. Conversion is a valve, not a dial — which is why every rule in this article reduces to one habit: treat originals as originals. Convert copies, keep the source, and any conversion mistake costs you a redo instead of a photograph.
Takeaways.
The thing to remember: conversion = decode to raw + re-encode from scratch. Expect four losses: lossy generations stack, target-format gaps truncate silently (alpha, animation, HDR, selectable text), metadata handling is a coin flip unless stated, and rasterization never reverses. Convert once, from the original, and keep the original.
Converters aren't doing anything mysterious or malicious — the losses are inherent to re-encoding, not flaws in the tool. Knowing the pipeline just moves you from "why does it look worse?" to choosing, deliberately, what you're willing to lose.
Convert files in your browser.
Paperwork converts between images and PDFs entirely client-side — your files never upload anywhere, which matters most for exactly the personal photos and documents people convert. What you lose to the format, you at least don't also lose to a stranger's server.
Open Paperwork