The PR adds docs/images/og-pricing.png. In Slack it looked like a product shot. In the file, it’s a 2560×1440 desktop capture: the URL bar, a bookmark row, a slice of the dock, and 200px of wallpaper on each side. Every social preview will show your browser chrome before it shows the pricing table.
I’ve started treating uncropped captures used as OG / hero / docs images as a packaging bug. Resize helps when the whole frame is the subject. Crop is what you need when the subject is a region inside the frame.
How chrome sneaks in
Common paths:
- OS screenshot of the whole window, “we’ll crop later”
- A device-frame tool that still includes the tab strip
- A sliding window of a long page, with the leftover sidebar still in view
- Copying a Slack / Notion image that was already a messy capture
og:image and GitHub social previews are unforgiving. They scale to a 1.91:1 (or similar) box. Browser chrome becomes a branded border you didn’t design.
A simple crop policy for repo images
- Subject — the UI surface you mean to show, not the window around it
- Aspect — crop to the ratio the host actually uses (often 1200×630 for OG, or the docs hero ratio)
- Text at the edge — leave a little padding; don’t clip the last letter of a heading
-
Name —
og-pricing.png, notScreen Shot 2026-11-11 at 9.41.03 PM.png
If the same capture is also a master for marketing, keep the uncropped original outside the repo and commit only the cropped derivative.
Crop before commit (not after the first LinkedIn preview)
You want:
- A visible crop frame you can drag, not a guess in CSS
object-position - Aspect-ratio lock when the destination is a fixed OG size
- A preview of the exact pixels you’re about to download
- PNG when the UI has sharp text or transparency; don’t flatten by accident
- No mandatory upload of an unreleased screen to a stranger’s server
When the file is already on disk and you’re in the browser, an in-tab cropper is enough. Uwarp’s crop tool lets you drop or paste an image, drag the frame, preview, and download a PNG locally. Useful for the one-off OG or docs figure. For a repeatable pipeline, use ImageMagick / sharp with a known crop box in the repo script instead of clicking through every release.
Caveats: cropping is not resizing — a 2400px-wide crop can still be huge; downscale after if the host doesn’t. Don’t stretch a 4:3 capture into 1.91:1 and call it a crop. Very large sources may hit browser limits.
Markdown / meta that matches the file
After you crop:
<meta property="og:image" content="https://example.com/og-pricing.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
Or in the README:

CSS object-fit: cover on a marketing site can hide a bad crop in your layout and still fail in Slack, iMessage, or GitHub’s own preview crawler. Crop the file.
Reject / send back
Reject
- Full-window screenshots used as OG images
- Bookmark bars, devtools, or notification toasts left in the frame
- Stretching instead of cropping to hit 1200×630
-
Screen Shot …filenames indocs/orpublic/
Accept
- Subject-only crops at the destination aspect, with modest padding
- Predictable names, alt / OG text that describes the UI (not “screenshot”)
- Masters stored outside the repo when design will reopen them
- A later resize pass if the cropped PNG is still multi‑megapixel
Tiny habit
Before you commit a fresh capture as an OG or docs hero, look at the edges. If you can still see the browser chrome, crop in the tab (or CLI), keep the master elsewhere if you need it, and commit the subject. The preview should show the product, not the toolbar you used to take the picture.
Top comments (0)