A screenshot is usually described by its size: 1920 wide, 1080 tall, 2.1 MB. That is only one of the things the file holds. Underneath the picture, every screenshot also carries a pixel grid, a DPI number and, on a modern Mac or a wide-gamut Windows laptop, a colour profile. None of these change what the image contains. All of them change how it is displayed somewhere else.
Most of the confusion around screenshots — "it looks different here", "it pasted in smaller", "the colours are off" — comes from one of those three, not from the pixels.
The pixel grid comes first
Every screenshot has a fixed width and height in pixels, and that number never changes when the file moves. What changes is the scale at which it is drawn.
On a Retina Mac, the layout is measured in points but rendered at twice the pixel count, so a 400 × 300 point selection is stored as an 800 × 600 pixel image. Windows at 150% scaling is the same idea: a 1920 × 1080 layout is captured at 2880 × 1620 physical pixels. The capture is not "too big". It has the number of pixels the screen actually had.
The practical rule is to check the real pixel count before deciding anything looks wrong. In Finder, select the file and press Command-I. On Windows, open Properties. If the image is roughly double what you expected, it is a high-density capture and the problem, if any, is downstream.
The DPI number, and why it is usually a lie
Next to the pixels, the file stores a resolution figure, usually 72 or 144 DPI. It is metadata, not a setting. It tells programs "if you have to print this or place it in a layout, assume this many dots per inch".
Almost no screen application uses it to decide display size, but a few do. Layout tools, Word, Keynote and some PDF exporters will read it and scale the image accordingly. That is why the same PNG can paste into one place at a comfortable size and into another at double size: nothing about the pixels changed, only the number the receiving app chose to believe.
The macOS built-in screenshot tool writes 72 DPI regardless of the display, and so does most capture software, including InSnap. A Retina capture therefore arrives as a large image with an ordinary DPI number attached. That combination is exactly why a slide deck that respects DPI shows it at double size: it sees "72 dots per inch" and does the arithmetic on the real pixel count.
The colour profile, the one people miss
This is the part that is invisible until it is not.
On a wide-gamut display — a Mac with a P3 panel, or a Windows laptop with a wide-gamut screen — the system does not store colours as plain sRGB. It stores them encoded for the Display P3 space and attaches an ICC profile to the file describing which space it is. A program that reads the profile converts back to what you saw. A program that ignores the profile reads the raw numbers and shows something slightly different.
How different depends on the colour. Neutral greys barely move, because white and black sit at the same point in both spaces. Saturated colours move a lot: a saturated blue can shift by more than 50 out of 255 on a single channel.
Load a screenshot in an application that does not carry the profile forward — an editor that re-saves without it, some web uploaders, some chat clients — and the file keeps the same pixels but loses the instructions for reading them. Every viewer after that treats it as sRGB, and the colours drift.
What an edit-and-resave actually does
Editing a screenshot and saving it again is a place where profiles quietly vanish. Many tools decode the image, throw the metadata away and write a new file containing only pixels. The image looks the same in the tool. Open it elsewhere and the colours are not quite right.
The check is the same one from above: before and after an edit, look at whether the file still has an embedded profile. On Mac you can see this in Preview under Tools › Show Inspector and read the ICC Profile line. If it says "sRGB IEC61966-2.1" before and "sRGB IEC61966-2.1" after, you are fine. If it said "Display P3" before and is empty after, the tool dropped it.
If the tool is yours to choose, prefer one that preserves the profile. If it is not, the workaround is to export from a source that already carries the profile and avoid round-tripping through a lossy or profile-stripping editor unless you need to.
Which of the three actually matters
| Metadata | When it matters | When it does not |
|---|---|---|
| Pixel dimensions | Always; they define the image | Never — they do not change |
| DPI figure | Placing in layouts, Word, PDF | Viewing on screen, uploading |
| Colour profile | Wide-gamut displays, colour review, design handoff | Flat UI screenshots, black-and-white text |
For a bug report, a code snippet, a chat screenshot, only the pixel count matters. For a design review or a colour-sensitive comparison across machines, the profile matters more than any other property of the file.
How InSnap handles each one
InSnap captures the real device pixels, so on a Retina display a selection of 400 × 300 points is stored at the pixel count the screen actually had. It converts captures to sRGB at capture time, so the pixels you save are the colours you saw on your particular display, and every viewer treats them the same way. There is no separate "convert to sRGB" switch, because there is nothing to convert: the file is already sRGB.
The selection label shows the size in physical pixels while you drag, so you see the real pixel count before you copy or save. If you later want a smaller, layout-friendly copy, Settings › Save has a Scale Retina to 1x option that resizes cleanly while writing the file.
FAQ
Why does the same screenshot look different in two apps?
Usually one app reads the embedded colour profile and the other ignores it. If the file carries a Display P3 profile and a viewer treats it as sRGB without converting, saturated colours look different. Flat white, black and grey areas stay the same.
Does resizing a screenshot break the colour profile?
Not by itself. Most resizers preserve the profile if the tool carries it forward. The broken case is a tool that strips metadata entirely during save, which is common in simple editors and some web uploaders. Check the ICC Profile line in Preview or any inspector before and after.
Why does a Retina screenshot paste into a slide deck at double size?
The file has the real pixel count of a 2x display, roughly four times the point area. Some layout tools read the DPI metadata and scale it down, many do not. Exporting from InSnap with Scale Retina to 1x produces a 1x-sized copy for those tools.
Is a PNG with a P3 profile bigger than the same PNG in sRGB?
Slightly. The ICC profile adds a few kilobytes. The pixel data is usually the same size, because PNG compresses both similarly. The difference is not a reason to strip the profile.
Should I keep screenshots in sRGB or in the display's wide gamut?
If they are going to other people, sRGB is the safe answer: the colours look the same on any screen that respects it. If you are reviewing colour on your own calibrated display and comparing to another display that is also wide-gamut, keep the profile as captured. For anything shared with a team or sent to a customer, sRGB.
Originally published at https://insnap.app/blog/what-a-screenshot-file-carries/.
Top comments (0)