Cmd-Shift-4 is the most-used design tool in the industry and nobody would defend it as one. It is the default because it is available everywhere, costs nothing, and takes half a second. Those are real advantages and this post is not going to pretend otherwise.
It is worth being precise about what it costs you, though, because the cost is invisible at the moment you pay it and enormous at the moment you need what you gave up.
What a screenshot throws away
The browser computed a large number of exact values in order to paint that frame. A screenshot keeps the frame and discards every value.
Concretely, gone:
- The type stack. You can see it is a geometric sans. You cannot see that it is a variable font at weight 480 with -0.011em tracking and a 1.45 line height, and you will get all three of those slightly wrong by eye.
- The spacing scale. Pixel-counting a screenshot gives you numbers that are close and not the scale. 14, 22, 34 instead of 16, 24, 32, and now the rhythm is subtly off and you do not know why.
- The real colours. An eyedropper on a screenshot samples the blended result. A surface that is white at 6% over a #0B0B0F ground reads as #1A1A1E, and if you use #1A1A1E you lose the translucency that made it sit correctly over the background image.
- Everything with a duration. Hover states, focus rings, the transition, the loading state, how the thing behaves while data is arriving. A screenshot is one frame out of an interaction that had several.
- The reflow. What this looks like at 1024, at 768, at 390. Frequently the most interesting decision in the whole component.
- The structure. Whether that is a grid with a span, a flex row with a wrap, or absolutely positioned. Three different implementations, one identical picture.
When a screenshot is still the right call
It genuinely is, sometimes. Take the screenshot and do not feel bad when:
- You are capturing composition or feel rather than implementation. Mood, density, restraint, how the whole page hangs together.
- The thing is not a web page. A native app, a video, a physical object, a slide someone is showing.
- You are on a phone.
- You are documenting a bug or a moment in time and the point is exactly the frame.
The mistake is not taking screenshots. The mistake is taking screenshots of a live web page, which is the one case where something strictly better exists and is one keystroke away.
The upgrade: capture the element
On a web page, the alternative is to capture the element itself: its markup, its computed CSS, and the assets it needs, packaged so it renders on its own. The picture is still there, but now it is the least interesting thing in the capture.
What that buys you, concretely: you can read the real values instead of guessing them, the reference keeps working after the source site is redesigned, you can diff two references against each other, and you can hand the whole thing to a code generator or an AI agent as structured input rather than as an image it has to interpret.
The cost is that it needs a browser extension, and that it only works on the web. Which is why the honest answer is "both": element capture for web pages, screenshots for everything else, in the same library.
Rescuing the folder you already have
Assume you have 2,000 PNGs named after timestamps. You are not going to rename or tag them, and any plan that requires you to is a plan that will not happen. Three things actually work.
First, OCR the lot. Interface screenshots are full of text, and interface copy is unusually distinctive. "you have no projects yet", "seats", "resend invitation". Once the text inside images is indexed, a huge fraction of the folder becomes reachable by search, with zero manual effort. This single step recovers more of an old screenshot folder than anything else you can do to it.
Second, index them for semantic search. This is what makes "dark settings page with a segmented control" find something you never described in those words.
Third, prune on read, never on a schedule. When a search surfaces something you no longer care about, delete it in that moment. Do not plan a cleanup day. Cleanup days do not happen, and the guilt of a cleanup day you did not do is itself a reason people stop opening the folder.
Naming and folders, briefly
If you are going to keep a plain folder, two rules pay for themselves and no more than two:
- Put the source domain in the filename. Not the date, not a description. The domain is the one piece of metadata you will actually want and the one your OS cannot recover.
- Keep exactly one level of folders, by kind of thing rather than by project. Navigation, forms, empty states, pricing, onboarding. Ten or so, stable for years.
Everything beyond this is a taxonomy you will maintain for six weeks. Search is what scales; structure is what makes you feel organized while the library quietly stops being usable.
What this looks like in Stele
Stele exists because of the gap this post describes. The Chrome extension captures elements, regions, full pages, and recordings; an element capture carries its real DOM and computed CSS, so it stays inspectable and buildable after the original page changes. Regions and pages still give you the flat image when the flat image is what you wanted.
Everything lands on one canvas with full-text search, OCR over images, and semantic search across all of it, so old screenshots and new element captures are searchable through the same box. From a capture you can read extracted design tokens, run a contrast audit, and generate React or HTML with Tailwind.
If you take one thing from this: on a web page, stop screenshotting. Everywhere else, screenshot away, and make sure the pile is searchable.