Record a Screen-Demo Reel Without Tiny, Blurry Text

A screen demo can look sharp on your laptop and still be unreadable in a Reel. The problem may not be the recorder. You might be squeezing an entire desktop, browser sidebar and face camera into a narrow vertical frame, leaving the important label only a few pixels high.

The practical fix is to design the explanation for a phone before recording. Show one meaningful part of the interface at a time, enlarge what needs reading at the source, and keep enough context for the viewer to understand where the action happens.

The examples below are original capture plans, not recorded comparisons. Use the worksheet to make and evaluate your own samples. We are not claiming a particular resolution, encoder or app setting has been tested on your device.

Decide what the viewer needs to read

Write a short action list before opening the recorder. For an illustrative scheduling demo: open the project, select the due-date field, choose a date, confirm the saved result. The viewer does not need to read every navigation item, account setting and browser tab.

Mark three types of text: essential labels, helpful context and irrelevant interface. Essential labels must be readable in the final frame. Helpful context can appear in an establishing shot. Irrelevant interface can usually be cropped out or hidden.

Build the demonstration in a safe workspace. Use invented names and sample data. Close private tabs and disable notification previews where possible. Check the entire recorded frame, including the browser address bar, file picker and tooltips; hiding customer names in the main panel alone is not enough.

Design the vertical frame first

Create a vertical editing sequence appropriate for your intended output. As an illustrative layout, reserve most of the middle for the active interface, a small area above for the task name and a separate area below for captions. These are layout choices, not permanent Instagram safe-area coordinates.

Try the layout with a still image before recording. View it on your phone at a normal viewing distance. If you need to pinch-zoom to read the button, the demo needs a tighter view or larger interface text.

A large face camera is optional. If it takes away the space needed to understand the software, use a brief presenter introduction and then show the demonstration full-width. The face is not automatically more important than the task.

Capture the right source, not everything

In OBS, scenes contain sources such as a window, display or capture device. Its Sources Guide documents source selection, positioning, resizing and cropping. On current macOS versions, use the documented macOS Screen Capture source where appropriate rather than assuming an older Window Capture tutorial still applies.

Window capture can reduce accidental inclusion of unrelated desktop content, but it does not make information inside the selected window safe. Inspect pop-ups and account details before recording.

The OBS overview distinguishes the base canvas from the output resolution. Avoid casually shrinking a detailed source at one stage and enlarging it again later. Keep track of the capture size, sequence size and export size so you know where scaling happens.

Make three small samples before the full take

For the scheduling example, record the same action three ways:

These are proposed samples for your own test, not results. Pick the option that explains the action best. A tighter crop is not automatically better if the viewer cannot tell which panel they are in.

Use browser or application zoom where it preserves a workable layout. Enlarging real text before capture differs from scaling up already recorded small text. Check menus and dialogs too: they may not respond to the same zoom control.

Record deliberate actions

Move the pointer to the relevant control, pause, then click. Let the result appear before continuing. Avoid circling the pointer continuously while speaking; it gives the viewer another moving object to track without adding information.

If you make a mistake, repeat the complete action from a recognisable starting point. Keep the original take until you have a clean replacement. Do not rely on a rapid zoom to hide a confusing click sequence.

Record narration separately if speaking and operating the interface makes both harder. In the narration, name controls and outcomes: “Open Due date, choose Friday, then confirm that Friday appears on the task.” That is more useful than “click here, then this.”

W3C's visual-information guidance supports describing important visual actions in the audio. This also makes a software demo less dependent on a viewer following every cursor movement perfectly.

Find the stage that introduces blur

Check the original recording first. If the text is already soft there, fix the capture area or source scaling. Exporting at a larger resolution cannot recover letters that were never recorded clearly.

Next inspect the editing sequence. Is the clip being enlarged substantially? Did a nested sequence or preview setting make you mistake a low-quality preview for a bad source? Compare a short export with the original instead of judging only the editor's playback window.

Finally inspect the exported file on a phone before uploading. Check the title, button labels, date values, captions and pointer. If the export is readable but the posted video is not, you have a separate upload/playback problem, not proof that every screen recording needs new capture settings.

Keep a reusable demo layout

Save the chosen capture area and text size with the worksheet. Keep a neutral demo dataset so the next tutorial does not begin with a privacy cleanup. Store the original recording as well as the finished export.

Your final check is simple: can a viewer describe the task, identify the relevant control and see the result without pausing every frame? If not, narrow the lesson or give the action more room. The storyboard guide helps split a crowded demonstration into a sequence of readable steps.

SCREEN-DEMO REEL QA
Record your own samples. This worksheet does not contain measured results.

Task:
Viewer:
Essential labels:
Context needed:
Private information to remove:
Safe sample data:

CAPTURE LOG
OS/app/version:
Capture source:
Source/window size:
Application/browser zoom:
Canvas size:
Output recording size:
Editing sequence size:
Export size:
Caption area:

THREE-SAMPLE TEST
A | whole desktop | readable? | context? | private data?
B | larger interface text | readable? | context? | private data?
C | active panel close-up | readable? | context? | private data?
Chosen sample and reason:

WORKED PLAN
Task: change a task due date.
Step 1: show project context.
Step 2: focus on Due date.
Step 3: select Friday.
Step 4: hold on saved Friday value.
Narration: name the control and confirm the result.
Data: invented task, no customer names.

DIAGNOSIS
Original recording: sharp/readable?
Editing view: scaling or preview issue?
Export on phone: labels/captions readable?
Uploaded playback: same or different?
Stage to change:
One changed setting:
Retest result:
Final privacy check: