When a Screenshot Belongs in Git, Not in History
By Khushi Yadav
A screenshot that decides whether a build is good is not a clipboard item. It is a baseline: a file with a name, a reviewer, and a history of who changed it. Windows clipboard history is the opposite object. Microsoft documents 25 entries, 4 MB per item, text / HTML / bitmap, and a restart wipe of everything unpinned. Pins still have no path, no diff, and no pull request.
This is an opinionated split for design-system and QA teams. Ephemeral snips can stay in history for an afternoon. Anything that would be painful to recapture from memory belongs in git — or in a dedicated visual service that git references.
Two jobs, two stores
| Question | History (Win+V) | Git (or git-LFS / screenshot service) |
|---|---|---|
| What is this? | The last pasteable bitmap | checkout-empty-desktop.png at commit abc123 |
| Who changed it? | Unknown | git blame / PR |
| Can a teammate see it tomorrow? | No, not from your clipboard | Yes, after push |
| Survives reboot? | Only if pinned, still local | Yes |
| Diffable? | No | Image review in the PR, or CI pixel diff |
| Max practical set | 25, then eviction | Repo policy and LFS budgets |
History is a recents list. Git is a record. Using the recents list as the record is how baselines evaporate after a Windows Update or a laptop restart. Related: Clipboard History Cleared After Restart? That Is Normal.
Screenshots that belong in git
Put a file in the repository (or in LFS / an artifact store the repository points at) when any of these are true:
- Visual regression baseline. Playwright, Cypress, Storybook, Chromatic, Percy, or a homegrown
comparestep treats this PNG as the expected pixels. - Docs figure. The page in the design-system site or the README will break if the image is missing.
- Bug evidence that must survive the ticket. Legal, security, or long-running incidents. The tracker can also hold the file; git is right when the evidence is tied to a commit.
- Shipped marketing or UI chrome that the product builds consume (
src/assets/...). - Pair of before/after images that a future reviewer must reopen. Comparison itself is not a clipboard feature: Visual Diff: Two Screenshots Side by Side.
Name the file before the first commit: Turning a Copied Image Into a Named Asset.
Screenshots that should stay out of git
- A snip to ask a teammate “is this padding wrong?” in Slack, then delete.
- Ten nearly identical tries while lining up a crop.
- Images that contain secrets, customer PII, or unreleased legal copy. Those should not be in history or git. Redact or recapture with dummy data.
- Multi-megabyte 4K desktop dumps. Even if LFS can store them, they are usually the wrong artifact; crop to the control.
If the only destination is a chat thread, save a file to a ticket, not to main.
Why “I’ll pin it” is not version control
Pinning is Microsoft’s answer to the restart wipe. It is a local flag on a history slot. It does not:
- Create a path another checkout can open
- Record a commit message
- Survive a new Windows user profile, a replaced laptop, or some feature updates
- Provide review
- Work for files (history is not a file library)
Pins also consume the 25 slots. Twenty pinned baselines leave almost no room for ordinary copies. That is the opposite of how a baseline set grows.
A practical repo layout
Keep screenshots next to the thing they document, not in a single misc/ dump.
docs/components/button/button-primary.png
e2e/snapshots/checkout-empty-desktop.png
src/assets/empty-states/inbox-zero.png
Rules that prevent pain:
- One purpose per file. Do not reuse
button.pngfor three stories. - Stable names. Changing a filename is a reviewable diff. Changing pixels in the same name is a visual diff.
- No Desktop paths in docs. Markdown that points at
C:\Users\...will not build on CI. - Compress with intent. PNG for UI chrome with text. Do not JPEG a baseline if the test is pixel-exact; compression noise becomes a failed test.
Git LFS
Large binary PNGs in plain git make clones slow and diffs useless. Git LFS stores the bytes outside the main object graph and leaves a pointer in the commit. Use LFS when:
- Baselines are numerous or large
- The team already has LFS hosting enabled
LFS is still git: the pointer is reviewed, the bytes are fetched on demand. It is not clipboard history with a longer timeout.
Hosted visual services
Chromatic, Percy, and similar products keep baselines in their store and comment on the PR. The git repo holds the test that took the shot, not always the PNG itself. That is still “not Win+V.” The record lives in a system with auth, review, and retention.
Capture into git without using history as the middleman
- Reproduce the state in the app.
- Capture with Snipping Tool or the test runner. Prefer the test runner for anything that must match next month; humans cannot recapture the same anti-aliasing.
- Save or export into the path above.
git addthe file. Write a commit message that says what changed in the UI, not “update screenshot.”- In the PR, look at the image diff the host provides.
If a human snip is unavoidable, save from Snipping Tool (Save as), then add the file. Do not paste from Win+V into a web uploader as the only copy. Browser editors have their own paste limits: Canva, Photopea, and Browser Editors: Paste Limits.
History can still hold the URL, the expected error string, and the ticket id while writing the commit message. That is a good use of a 25-item list. Enable it: How to Enable Clipboard History in Windows 11. Paste those strings without mystery fonts: How to Paste Without Formatting on Windows.
CI will not read your clipboard
This is the decisive test. If a GitHub Actions or Azure Pipelines job must see the image, it has to be in the checkout, in LFS, or downloaded from a store the job can authenticate to. No CI agent can open Win+V on a developer laptop. Designing a process that requires that step guarantees a broken main branch the first time someone is on vacation.
Optional local shelf while assembling the PR
Dragging three new PNGs from a capture burst into e2e/snapshots/ is easier if they sit on a local shelf for ten minutes. Edge-Drop can hold those files for the drag. After git add, the shelf is done. Do not treat the shelf as the remote, and do not skip the commit.
ShareX can write directly into the snapshots folder with a patterned name: Using ShareX After-Capture Plus a Clipboard Shelf.
Retention and secrecy
- Delete unpinned history after a session that included staging URLs or tokens: How to Clear Clipboard History on Windows 11.
- Never commit a snip that includes production data. Rotate anything that leaked.
- License third-party UI shots before they enter a public repo: UI Inspiration: Collecting Interface Shots Legally.
Related reading
- How to Get a Screenshot Into Photoshop Without Recopying
- How to Paste Without Formatting on Windows
- How to Enable Clipboard History in Windows 11
- Best Clipboard Managers for Windows in 2026
Sources
- Using the clipboard (Microsoft Support) — official 25 / 4 MB / format / restart limits that make history unfit as a baseline store.
- How to use clipboard history in Windows 11 (Microsoft) — pins are local convenience, not collaboration.
- Use Snipping Tool to capture screenshots (Microsoft Support) — Save as the path into the working tree.
- Git Large File Storage — official LFS project for versioning large binary assets such as PNG baselines.
Khushi Yadav is a B.Tech Computer Science Engineering student interested in technology, software, and exploring practical applications of computer science. She enjoys learning new concepts and contributing to technology-focused projects.
GitHub · LinkedInCopy. Stack. Drop.
Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.
Download for Windows Get from Microsoft Store
How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support
Free · Lightweight · Privacy First