Screenshot, GIF or video: which to send for which message

The right format is the one that lets the other person understand without asking you a follow-up question. That depends on whether you are showing a moment, a movement or a reason.

By the VeoRec team · Oct 3, 2026 · 11 min read

Screenshot, GIF or video: most people pick by habit. Designers paste screenshots, developers record GIFs, support teams send videos. The better way to choose is to ask what the person on the other end must understand, and which format gets them there without a follow-up question.

The answer is different for a bug report, a design note, a pull request and a support reply, and close calls are usually settled by dull practical limits rather than taste: how big the file gets, how many colours survive, whether there is sound, and whether the thing plays inline where the reader is looking.

Start from what the reader has to understand

Every visual message shows one of three things. Name which one before you capture anything.

• A state. Something looks wrong, or looks right, at one moment: a misaligned button, the wrong price on a pricing card, an error message. One picture holds all of it.
• A short movement. Something happens over a few seconds: a dropdown that flickers, a hover state that never appears, an animation that stutters. A still image cannot show it, and there is nothing to explain out loud.
• A sequence with reasons. Several steps lead to a result, and why each step matters is part of the message: how to reproduce a bug, how a feature works, why you chose one design over another.

State means screenshot. Short movement means GIF or a very short video. Sequence with reasons means video. Most wrong choices come from sending a sequence as a pile of screenshots, or a state as a two-minute video where the problem appears at 1:40.

When two formats both seem to fit, three more questions usually break the tie:

• Will they need to copy something? Error strings, URLs, IDs and code must go in as text, whatever else you send. No reader should retype a stack trace from a video frame.
• Where will they look at it? On a phone in a chat thread, a cropped screenshot beats a video they cannot hear in a meeting room. At a desk, investigating, a video with sound is fine.
• Will anyone come back to it? A one-off question can be answered with whatever is quickest. Material people return to, such as a handover or a how-to, deserves the format that explains best, even if it takes longer to make.

Send a screenshot when one moment tells the story

Screenshots are the fastest format to read. A developer scanning thirty tickets can take in a cropped screenshot in a second, without pressing play, without sound, in any tool. If one frame is enough, nothing beats it.

Choose the size of the capture to match the problem. A selected area is best when the issue is in one component, because the reader's eye lands on it immediately. The visible area works when the surroundings matter, such as a modal on top of the wrong page. A full scrolling page shows layout problems further down, like a footer overlapping content on a long pricing page, in one image instead of six.

Format matters more than people think. MDN's image format guide recommends lossless encoding for screenshots, diagrams and line art, because lossy compression blurs text and sharp edges. PNG is the safe default for screenshots of interfaces; heavy JPEG compression is how "the label is cut off" becomes "the label is a smudge".

A screenshot fails when the problem is a change over time ("it shows the old price for a second, then updates"), when the cause is several steps back, or when the reader needs to hear what you expected. If you notice yourself adding arrows labelled 1, 2, 3 and 4, you have a sequence, and it wants to be a video.

Send a GIF when the movement is short and silent

A GIF is a tiny looping video that plays inline almost everywhere: in issue trackers, chat tools and pull request descriptions. It is perfect for a few seconds of motion that needs no explanation: the hover state in a pull request, the spinner that never stops, the menu that opens and immediately closes.

GIF is also an old format, and it shows in three ways:

• Limited colour. Each frame has a palette of at most 256 colours, per the GIF89a specification. Interfaces with gradients, shadows or photos show banding, which can hide exactly the visual bug you are reporting.
• No sound. The format is for graphics only. If your voice or the page's audio matters, a GIF cannot carry it.
• Large files. In web.dev's example of replacing GIFs with video, a 3.7 MB GIF became a 551 KB MP4 and a 341 KB WebM. Long GIFs grow quickly and can hit attachment limits.

Those limits suggest a rule of thumb: two to ten seconds, cropped tight to the area that moves, no text the reader must study frame by frame. Past that, a short video is usually smaller, sharper and easier to pause. MDN's guide makes a similar point for websites, suggesting modern formats rather than GIF for animation.

Also check that a GIF is really what the destination wants. Some trackers and chat tools play short MP4 or WebM files inline too, with a pause button and better colour. If yours does, a five-second video clip gives you everything a GIF does without the banding. Keep GIF for the places where nothing else autoplays.

A common way this goes wrong: a developer records a 25-second checkout flow as a GIF for a pull request, at full window size. The file comes out well over GitHub's 10 MB limit for images and GIFs, the upload fails, and the second attempt is a GIF squeezed to a smaller palette in which the bug, a faint grey border that flickers, has disappeared into the banding. The fix is to split the job: a four-second GIF cropped to the component that flickers, inline in the description, and the full flow as a video link underneath for anyone who wants the context.

Send a video when the sequence, timing or reasoning matters

Video is the only one of the three that carries order, timing and your voice together. Use it when any of these is true:

• The problem appears only after several steps, and the steps are part of the evidence.
• Timing matters: a slow response, a double submit, a toast that disappears before anyone can read it.
• The bug is intermittent and you finally caught it: record now and explain later.
• You need to explain why, not only what: a design rationale, a trade-off in a pull request, a "this is what I expected to happen".
• The reader will want to pause and try it themselves while watching.

Video is also the format most often sent when it is not needed. A two-minute recording of a typo in the footer asks a developer to press play, wait, and hunt for something a cropped screenshot would have shown in one glance. If the problem is visible in a single frame and you have nothing to explain, the recording is a courtesy to yourself, not to the reader.

The cost of video is that the reader has to press play and spend the time. Respect that by stating the point in the first sentence, showing the steps at normal speed, and stopping as soon as you have shown the problem and said what you need. A 40-second recording with narration often replaces a long written reproduction and three follow-up questions.

Shared as a link rather than an attachment, a video has no size problem and stays watchable in any browser. When you record a bug in VeoRec, clicks are highlighted, you can drop a chapter marker where it breaks, and the link is copied as soon as you stop, so it goes into the ticket as fast as a screenshot would.

Compare the three side by side

Read the table by row, not by column. If sound matters, only one format qualifies. If the reader is scanning a queue, the screenshot wins even if a video would be more complete.

For bugs, answer three questions

Bug reports are where the choice matters most, because a wrong format costs a round trip with the developer. Three questions settle it: does it take clicks or typing to make it happen, does timing matter, and is the problem further down a long page? Try it with a bug you saw this week:

Whatever the format, the visual is evidence, not the report. A bug report still needs a title, the environment, expected and actual behaviour, and the steps. The guide on how to write a bug report covers the written part, and video bug reports covers what to show in the first ten seconds of a recording.

Check file size before you attach anything

Attachments have limits, and they bite at the worst moment. GitHub's documentation on attaching files, for example, lists 10 MB for images and GIFs, 10 MB for videos in repositories on a free plan and 100 MB on paid plans at the time of writing (October 2026), with MP4, MOV and WebM accepted. Email providers and chat tools have their own ceilings.

Recordings grow with length, resolution and frame rate. Use the calculator to see roughly how big a recording would be as a file:

If the number is close to the limit of the tool you are sending to, share a link instead of the file. A link also means you can trim or blur the recording afterwards without sending a new attachment, and everyone sees the same version. For the trade-offs between resolution, frame rate and size, see screen recording settings explained.

Match the format to where it will be read

The same message can need a different format depending on where it lands. Readers behave differently in a chat channel than in a ticket queue or an inbox.

Chat

People skim chat between other things, often on a phone. Screenshots and short GIFs work well because they show up inline and need no click. A video link in chat should come with one sentence saying what it shows and how long it is, so people know whether to watch now or later.

Ticket trackers

Tickets are read twice: once quickly at triage, and once carefully by whoever fixes the problem. Put the fastest format at the top (a screenshot of the broken state) and the complete one below (the recording). Attachments that are too big simply fail, so links are safer for anything longer than a few seconds.

Email

Most email clients show images inline but not videos, and large attachments bounce. For a client or a stakeholder, a clickable thumbnail that opens the recording in the browser works better than an attached file. In Gmail, VeoRec adds a Video button that inserts exactly that kind of thumbnail.

Documentation and help articles

Here the question is maintenance. Screenshots go stale every time the interface changes, but they are quick to replace one at a time. Videos explain a workflow better and take longer to redo. A good split is screenshots for each step, plus one short video for the whole task, recorded once the interface has settled.

Often the best answer is two formats

You do not have to pick only one. Some of the clearest messages combine a fast format for scanning with a complete one for investigating.

• Ticket: screenshot plus video link. The screenshot of the error goes in the description so triage can understand it at a glance. The recording link below it shows how you got there.
• Pull request: GIF plus written notes. A three-second GIF of the new hover state in the description, with the reasoning in text. Add a short walkthrough video only if reviewers need to understand a flow.
• Design feedback: annotated screenshot plus a short recording. Mark the three spots on a full-page screenshot, then record a minute explaining why the hierarchy feels off.
• Support reply: video plus the steps in text. The customer watches once and then follows the written steps while doing it themselves.

A concrete example: on a checkout page, the total briefly shows the price without tax and then jumps. A screenshot catches only one of the two states. A GIF shows the jump but not what triggered it. A 25-second recording that starts on the cart, changes the shipping country and lands on the jump, with one sentence of narration, shows everything. Paste a screenshot of the wrong total above the link and the ticket works for everyone who reads it.

Make each format readable

Screenshots

Crop to the part that matters, plus enough surroundings to know where it is. Mark the problem with one box or arrow, not five. Hide personal data before you capture, because blurring later is easy to forget. Give the image a sentence of alt text or a caption that says what is wrong, for anyone using a screen reader and for search.

GIFs

Record only the region that moves. Start just before the movement and stop just after, so the loop is easy to follow. Avoid text the reader must study, because they cannot pause it in many tools. If the GIF is over a few megabytes, turn it into a video.

Videos

Zoom the page so text is readable at a smaller size, turn off notifications, and say the point in the first ten seconds. Captions help viewers who watch without sound and anyone who cannot hear the audio. Screen recording accessibility covers captions, pace and contrast in more detail.

One tool for all three saves a lot of switching. The VeoRec extension takes screenshots of the visible area, a full scrolling page, a selected area or the screen, and records the tab, a window or the whole screen with your voice, so you can pick the format after you have seen the problem. The full-page screenshot page shows the long-page capture.

What to do next

Look at the last five visual messages you sent. For each, ask whether it showed a state, a short movement or a sequence with reasons, and whether the format matched. Most people find one habit to change: usually a pile of screenshots that should have been a 40-second video, or a long video that should have been one cropped image.

Then agree on defaults with your team: screenshots in ticket descriptions, GIFs only for short motion in pull requests, recordings as links for anything with steps. Write them down where people file bugs, so the next report arrives in the right format the first time.