How to use screenshots in X posts as a developer (what to capture and how)

By Naod Tadele · November 10, 2026 · 6 min read

You shipped something you can see. A new settings page, a faster dashboard, a chart that finally makes sense. Then you describe it in two sentences of text, and nobody can picture it.

A screenshot fixes that. It takes up more room in the feed than text alone, and it lets a stranger understand the update without reading closely. But a bad screenshot, a full browser window with tiny text, does almost nothing. This guide covers what to capture, how to frame it, and what to write next to it.

When a screenshot helps

Not every post needs an image. Use one when the update is something a person can see:

• A new feature with a visible surface. A page, a panel, a button that does a new thing.
• A redesign. Before and after, side by side.
• A result. A chart, a number on a dashboard, a faster load time shown in your tools.
• A real moment. The first customer email, a kind message, an error you finally fixed.

Skip it when the work is invisible, like a refactor or a dependency upgrade. A screenshot of a diff rarely helps unless the diff itself is the story, such as deleting a huge amount of code.

Capture one thing

The most common mistake is capturing everything. A full window shows your sidebar, your tabs, your bookmarks bar and, somewhere in the middle, the feature. On a phone, none of it is readable.

Pick the one thing the post is about and capture only that:

1. Crop tight. Cut the browser chrome, the sidebar and anything that isn't the feature.
2. Zoom in before you capture. Raise the browser zoom so the text is large. If you can't read it at arm's length on your laptop, nobody can read it on a phone.
3. Leave a little room. A small margin around the element looks cleaner than an edge to edge crop.

Clean up before you capture

A screenshot is a small ad for your product. A few minutes of setup makes it look cared for:

• Use realistic data. "Test test 123" and "asdf" make a product look unfinished. Fill in names and values a real user would have.
• Hide private data. Customer names, emails, API keys and revenue you don't want public. Check twice. A posted image is hard to take back.
• Close the noise. Dev tools, debug banners, notification badges and unrelated tabs.
• Pick one theme. Light or dark, and use the same one across posts so your images are recognizable.

Before and after

For redesigns and fixes, two images beat one. X lets you attach up to four images to a post, and two sit side by side in the feed.

Make the comparison fair and obvious:

• Same page, same data, same crop in both images.
• Old version first, new version second.
• Say in the text what changed, so people know where to look.

What to write next to it

The image shows what. The text should say why. Don't describe the screenshot, since people can see it. Give the context they can't see: the problem, who asked for it, or what it replaces.

A weak post for the fictional product Nightshift, which writes incident summaries for on-call engineers:

A better one:

The second post gives the reason, says what the image shows, and tells people it's real.

Add alt text

X lets you add a description to every image. Write one. It makes your post usable for people on screen readers, and it takes a few seconds.

Describe what the image shows and why it matters, in a sentence or two:

Nightshift timeline view showing an incident from first
alert to resolution, with each alert, acknowledgement
and deploy listed in order.

When to use a video instead

If the feature is about movement, like a drag and drop, a fast search or a flow with several steps, a still image undersells it. Record a short screen capture instead. The same rules apply: one thing, zoomed in, clean data, no wasted seconds at the start.

A quick checklist

1. Is the update something you can see? If not, skip the image.
2. Is the crop tight and the text readable on a phone?
3. Is the data realistic and free of anything private?
4. Does the text explain why, not what?
5. Did you add alt text?

How Loudcode helps

Taking a clean screenshot is easy to skip when you just want to get back to work. Loudcode drafts build in public posts for X from your GitHub commits, pull requests and releases, and on visual posts it adds a screenshot of your live app, so the update comes with something to look at. You review every draft, including the image, and nothing is posted until you approve it. For the writing side of a shipped change, see how to turn a pull request into a post.