IntactFile

Repair a corrupt PNG screenshot

Screenshots are the images people capture, auto-sync and paste more than any other — and each of those steps has its own way of leaving you with a .png that won't open. The good news is that the failures are predictable, the dimensions are usually recoverable, and there's often a faster fix than repair if you act before the clipboard or the original is gone.

When a screenshot saved as .png won't open, the viewer is usually strict about something the format lets it check exactly. Windows Photos says "It looks like we don't support this file format" or "This file can't be opened"; macOS Preview says the file "may be damaged or use a file format Preview doesn't recognize"; libpng-based tools throw IDAT: CRC error or Not a PNG file. This page is about why screenshots specifically end up broken and what to do about it; for the byte-level anatomy of a PNG — the signature, the chunk layout, the CRC-32 that guards each block — see the PNG CRC-error page. Drop the file above and the tool walks it chunk by chunk in your browser, rewriting a valid file around whatever is genuinely there. Nothing is uploaded; a screenshot often shows a bank balance, a private message or a medical portal, and it never has to leave your machine to be checked.

Your file never leaves your device — repair runs in your browser. 0 bytes uploaded.

Your data is the big block — usually intact. What breaks is the small index. Repair rebuilds it.

Drop a file here or browseTap to choose a file

ZIP · Office · PDF · video · JPG · PNG · RAR/7z · SQLite — repaired right here in your browser. Nothing is uploaded

0 bytes uploadedFree: 3 repairs/day — up to 500 MB video, 100 MB docs & archives, 50 MB photos. Free download. Single repair €5.90. No account required.

Fix it now

  1. Drop the file
  2. Repair runs locally
  3. Download the result

Where screenshot PNGs come from — and where they break

A screenshot's whole life is capture → write to disk → (usually) auto-sync → paste or share. Damage almost always enters at one of the last three steps, and which one leaves a fingerprint you can recognise.

  • Windows. PrtScn puts the image on the clipboard only — nothing is saved until you paste and Save As, so a crash loses it entirely. Win+PrtScn and the Snipping Tool write a real .png into Pictures\Screenshots, and that folder is frequently redirected into OneDrive. When OneDrive starts uploading a screenshot the instant it lands, a reboot or sign-out mid-upload can leave a truncated file — the classic "top of the image is fine, bottom is grey" result.
  • macOS. ⌘⇧3/4/5 saves a PNG (often colour type 6, RGBA, because window grabs keep a transparent corner) to the Desktop by default. If your Desktop is in iCloud Drive, the same mid-sync truncation applies. Force-quitting the capture UI or the floating thumbnail before the write flushes can also cut the file short.
  • Android. Screenshots land in DCIM/Screenshots or Pictures/Screenshots and back up to Google Photos. The fragile case is a scrolling or "capture more" screenshot: the OS stitches several frames into one tall PNG, and if that compositing step is interrupted the output can be malformed rather than merely short.
  • Pasted and re-downloaded. This is the one unique to screenshots, because they're the file people drop straight into Slack, Discord, Teams or a ticketing tool. Those services often re-encode on upload; download the result and any prior damage is now baked into new pixels, or the file you saved is actually an HTML preview renamed .png.
  • Sent through a text-mode bridge. A screenshot pushed through an FTP client left in ASCII mode, an old email gateway, or a script that rewrote it as text swaps every 0D 0A for a lone 0A (or the reverse). PNG's signature is deliberately built to detect exactly this, and when the substitution is consistent it reverses byte-for-byte.

Notice the pattern: the dominant screenshot failure isn't exotic corruption, it's a save or sync that stopped early. That's good news for recovery, because a short file still contains real pixels down to the cut.

Why a screenshot's dimensions are the recoverable kind

The one piece of damage that keeps a screenshot from opening yet fixes perfectly is a mangled IHDR — the 13-byte header that stores width and height. Zero those out and no decoder can allocate a canvas, so Photos or Preview simply refuse the file. But IHDR, like every PNG chunk, carries a CRC-32 that was computed back when the numbers were right, which means the correct geometry can be brute-forced: try candidate width/height pairs, recompute the chunk CRC for each, and stop when it matches the stored value. (The full mechanics of that CRC and the chunk it guards are on the PNG CRC-error page.)

Screenshots make that search almost trivial, because their dimensions aren't arbitrary — they cluster on a short list of display resolutions. A Windows grab is very likely 1920×1080, 2560×1440 or 3840×2160; a phone is a known panel size like 1080×2400 or 1179×2556; and a macOS Retina capture is the backing-store resolution, i.e. the point size doubled — a 14-inch MacBook Pro full-screen grab is 3024×1964, a 16-inch is 3456×2234. The pHYs chunk a screenshot often carries records that pixel density, so a Retina "@2×" grab even tells you its own scale. A geometry search that would be slow on an arbitrary image resolves in a handful of tries on a screenshot, because the answer is almost always a standard resolution.

What comes back — and what to try before you repair

Because the usual screenshot fault is a short file, the usual result is an honest partial: PNG writes its rows top to bottom inside one continuous compressed stream, so a truncated capture decodes cleanly down to where the bytes end, and the tool rewrites a valid trailer so a viewer will accept what survived. The rows below the cut were never written, so no tool can return them; damage landing inside the stream rather than at the end costs every row beneath it. (Why that stream can't resynchronise — and why a mid-stream hit is permanent — is explained on the PNG CRC-error page.)

Before you repair, though, a screenshot often has a faster escape hatch than any other broken file — try these first:

  • Is the subject still on screen? Re-taking the screenshot is the cheapest possible fix and gives you a pristine file. Do this before anything else if you can.
  • Windows PrtScn keeps it on the clipboard. If the saved file is broken but you haven't copied anything since, paste (Ctrl+V) into Paint or Photos and Save As a fresh PNG — the clipboard copy is independent of the corrupted file.
  • Check the other copy of an auto-synced shot. If the local file truncated mid-upload, the OneDrive / iCloud / Google Photos copy may be complete — or the reverse. Compare file sizes; the larger, later one usually wins. Download the cloud version fresh rather than trusting the synced placeholder.
  • macOS floating thumbnail still showing? Click it to reopen the capture and re-export before it dismisses — that in-memory copy hasn't been through the failed write.

When none of those apply, drop the file above: the chunk walk, CRC checks and stream decode all run as plain code in your browser tab, and you can open the Network tab to confirm 0 bytes leave — which matters when the screenshot shows a bank balance, a private chat or a password.

What this can and can't fix

Can fix

  • A screenshot truncated by an auto-upload folder (OneDrive / iCloud / Google Photos) catching the save mid-write — the rows written before the cut decode back as real pixels
  • Zeroed or scrambled IHDR width/height, recovered fast because a screenshot's dimensions are almost always a standard display resolution
  • A chunk whose stored CRC-32 no longer matches otherwise-intact data — the CRC is recomputed and the file validates with zero loss
  • Newline / text-mode mangling (CR-LF ↔ LF) from an ASCII-mode transfer or a chat bridge that rewrote the file as text
  • A missing or malformed IEND end marker on a file whose image data is otherwise complete

Can't fix

  • The rows below the cut in a truncated screenshot — those pixels were never written, and no tool can invent them
  • Image rows below a mid-stream IDAT hit — the compressed stream cannot resynchronise, so everything after it is noise
  • A screenshot a chat service or editor re-encoded after the damage — the wrong pixels are now baked in
  • A scrolling / 'capture more' shot whose stitching failed so badly that no complete frame was written
  • A file that reads as 0 bytes or all zeros — there is no image to rebuild (that is a data-recovery job, not a repair)

If a repair fails, we tell you why (missing data versus broken structure), and you are never charged for a failed repair.

FAQ

Why do my screenshots keep getting corrupted specifically?

Screenshots are auto-saved and auto-synced the instant you take them, so they're unusually exposed to a save or upload being interrupted. The most common cause is an auto-upload folder — OneDrive, iCloud Drive, Google Photos — starting to sync the file before the local write finished, leaving a truncated PNG. Pasting a shot into a chat app that re-encodes it is the second most common.

The bottom of my screenshot is grey or cut off — can I get it back?

Only if the missing part was never written (a clean truncation), in which case there's nothing to recover below the cut — the top comes back and a valid trailer is rewritten so it opens. If instead the damage landed inside the compressed data, everything below that byte decodes as noise. Either way the lower rows can't be restored; the repair returns an honest partial. Check whether a synced cloud copy is complete before settling for that.

My screenshot won't open but the dimensions look fine — what now?

If the header is intact but a decoder still reports a "CRC error", often only the stored checksum is wrong while the data is fine — recomputing it fixes the file with zero loss. If the data itself changed, the CRC is warning you correctly. The full walkthrough is on the PNG CRC-error page.

I pressed PrtScn but the saved PNG is broken. Is the image gone?

Maybe not. On Windows, PrtScn puts the capture on the clipboard independently of any saved file. If you haven't copied anything since, paste into Paint or Photos and Save As a new PNG — that copy never went through the failed write.

Is my screenshot uploaded to be repaired?

No. The file is read from your disk and rebuilt in your browser tab; the chunk walk and CRC checks are plain code running locally. You can open the Network tab and confirm 0 bytes leave — which matters when a screenshot shows a bank balance, a private chat, a password or a medical portal.

Related: PNG chunk & CRC anatomy · PNG chunks & CRCs, explained · Repair a JPEG photo