PNG, JPG, and WebP for OCR

Optical character recognition does not open a "document." It looks at pixels and guesses which shapes are letters. Sharp, high-contrast edges between ink and background make that guess easier. Soft, blocky, or ringing edges make it harder. Image format and compression are just different ways of storing those pixels, with different habits around detail.

Screenshot2Text accepts PNG, JPG, JPEG, WebP, GIF, and BMP in the same local reader, plus PDF pages when you use the PDF path. The format you drop still changes how clean the first pass looks.

This is everyday screenshot advice, not archival photography theory. Which file should you prefer when you still have a choice.

PNG is lossless for the color data it stores. Saving a screenshot as PNG does not throw away high-frequency detail to shrink the file. Thin interface fonts, one-pixel stems, commas, periods, and the difference between 1, l, and I stay closer to the original capture.

Desktop and phone OS screenshot tools often default to PNG for a reason. UI chrome is full of sharp vectors flattened into a bitmap. Lossless storage matches that content. If you still have the original PNG from the capture, use it. Do not re-export through a chat app that converts everything to a smaller lossy file "to help."

PNG files can be large on retina desktops. That size is usually fine for a handful of screenshots in the browser. If a huge desktop PNG stalls a phone tab, crop to the text region first. Cropping reduces pixels without inventing compression artifacts.

Dedicated landing copy for this path lives at /png-to-text. The reader is the same engine as the homepage.

JPEG (JPG) is a lossy format built for photos of the natural world. It discards detail the eye is less likely to notice in a landscape. Interface text is the opposite of a landscape. It is high-frequency, high-contrast, and unforgiving when coefficients get quantized.

A high-quality JPG of a clean scan can still OCR well, especially when type is large. A heavily compressed JPG from email, social media, or a messaging re-encode often shows mosquito noise around letters, muddy punctuation, and fused stems. OCR then confuses o and e, rn and m, or drops commas.

If your only copy is a JPG, try it. Raise the odds by cropping to the text, avoiding further re-saves, and keeping quality high when you control the export. Do not "optimize" a screenshot JPG down to a tiny byte budget right before OCR. You are deleting the edges the engine needs.

Camera JPEGs of paper under good light are a normal input. Camera JPEGs of another glowing monitor are a poor input because of glare and moire, regardless of the extension.

WebP can be lossless or lossy. Browsers and operating systems increasingly save screenshots and "Save image as" downloads as WebP. That is convenient for the web. For OCR, you need to know which flavor you have.

Lossless WebP behaves much like PNG for letter edges. Lossy WebP behaves much like a modern JPG: smaller files, softer or blockier type when quality is low. Chrome captures are often fine in practice, but a PNG export of the same frame usually keeps UI fonts a bit clearer when you still have both.

Screenshot2Text reads WebP locally the same way it reads PNG and JPG. The /webp-to-text landing speaks to people who already hold a WebP and want a direct path. You do not need to convert formats by hand before dropping the file. Conversion only helps when you still possess a sharper original.

Compression quality trades bytes for edge fidelity. Near the top of the dial, lossy formats still look fine to a person and often OCR acceptably. Near the bottom, shared memes and thrice-forwarded slides turn into soup.

In run 3 of our OCR accuracy test, on September 25, 2026, the same 22 screenshots had a mean character error rate of 0.65% as lossless PNG, 0.93% as WebP at quality 75, and 2.17% as JPEG at quality 30. In run 2, earlier that day, they had 1.16%, 1.51%, and 2.60%.

Rules of thumb for Screenshot2Text:

Prefer the original screenshot file over a copy that passed through chat compression.

Prefer PNG (or lossless WebP) for UI, terminals, dialogs, and small type.

Accept JPG when it is a decent scan or a large-type photo and you lack a lossless original.

Avoid stacking exports. Each lossy save can discard more of the same edges.

Crop before you shrink. Reducing resolution after a hard crop is different from crushing quality on a full desktop wallpaper shot.

GIF and BMP show up less often. GIF palette limits can posterize gradients and soft anti-aliased stems. BMP is usually fine but bulky. Treat them as supported, not preferred.

These are the full format results from run 3 of our OCR accuracy test, dated September 25, 2026. The same 22 screenshots (app screens, paragraphs, code, receipts, and chats) were saved in each format and read by the same in-browser code the tool uses. Character error rate (CER) and word error rate (WER) are lower-is-better. Word recall is the share of words that came back right.

Check the source app or OS screenshot folder before you grab the version sitting in Slack or iMessage. The local original is often PNG. The shared attachment is often a smaller JPG or WebP.

Open /png-to-text, /webp-to-text, /jpg-to-text, or the homepage. They share the same in-browser reader. Pick the language that matches the text. Drop the file. Skim the editable box. Copy or download .txt.

If results look soft or speckled, ask whether format is the culprit before you blame the engine. A crisp PNG of the same dialog is the control experiment. When the PNG reads clean and the crushed WebP does not, you have your answer.

Screenshot2Text will not invent detail that compression deleted. Local OCR still needs decent pixels. Format choice is one of the few upstream decisions that costs almost nothing and often saves a rewrite.