How to record your IDE and terminal so the code is readable

Code that looks fine on your monitor turns to grey fuzz in a pull request's video player. A few minutes of setup fixes it for good.

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

When you record your IDE and terminal, the code on screen is the whole point, and it is the first thing to become unreadable. Your monitor shows it crisp and small. The viewer sees it scaled down into a player embedded in a pull request, a chat thread or a wiki page, with video compression on top. Fourteen-point text on a large display ends up as a few blurry pixels per letter.

The fixes are boring and they work. Set them up once, in roughly the order below, and every walkthrough after that is readable by default: how much code to show, which window to capture, fonts and themes, a tidy screen, visible keystrokes, a calmer terminal, and no secrets. The examples use VS Code and JetBrains IDEs; the arithmetic is the same in Vim, Zed or anything else.

Count lines, not font points

Font size is the wrong thing to think about, because the same 14-point font produces very different results depending on your screen, your operating system's scaling and the recording resolution. What actually decides readability is simpler: how many lines of code fill the height of the frame, and how tall the player is when someone watches.

The arithmetic is simple. Divide the player height by the number of visible lines to get the height each line gets. A video recorded at 1080p and watched full screen has 1080 pixels of height. The same video embedded in a pull request or a chat preview often plays at around half that, or less.

So the target is roughly 25 to 35 visible lines. That sounds like very little code, and it is. It forces you to show one function at a time, which is what a viewer can follow anyway. For width, aim for about 100 characters visible, so typical lines do not wrap or disappear off the right edge.

To get there, zoom the whole editor rather than only the text. In VS Code, Ctrl and = (Cmd and = on a Mac) zooms the entire window, including the sidebar, tabs and terminal, so everything scales together. Changing only editor.fontSize leaves the terminal and the file tree tiny. JetBrains IDEs have a Presentation Mode that enlarges the editor to fill the screen with a larger font (JetBrains docs), and you can set the font size it uses in the Appearance settings.

Jump instead of scrolling

With only 30 lines on screen, you will move around the file more. Do it by jumping, not scrolling. Go to Definition, Go to Symbol and Go to Line move the view in one step, so the viewer sees one sharp frame and then another. Scrolling produces a second of moving text, which compression turns into a smear, and the viewer loses their place. If you must scroll, do it slowly and stop before you start talking again.

Record the editor window, sized to 16:9

Chrome's share dialog, which most browser-based recorders use, offers three choices: a browser tab, a window, or the entire screen. Chrome's developer docs describe the same three surfaces (source). For code, the choice matters more than people expect.

The window option is usually right. It captures exactly the editor, nothing else, and it keeps notifications out of the frame. The catch is that it captures only that window: if you switch to a separate terminal app mid-recording, the viewer keeps seeing the editor while you talk about something they cannot see. Use the editor's integrated terminal so everything stays in one window.

Then size the window to a 16:9 shape (1920 by 1080, or 1280 by 720 on a smaller screen). Videos are 16:9; a tall or very wide window gets black bars, which means the code occupies less of the frame. On a large monitor, a smaller 16:9 window with zoomed-in code often reads better than a full-screen recording, because it has fewer, bigger lines.

Worked example: the 1440p monitor

A common setup: a 27-inch monitor at 2560 by 1440, VS Code maximised, showing about 70 lines. Record the whole screen at 1080p and the recorder has to fit 1440 rows of pixels into 1080, so everything shrinks to three quarters of its size before compression even starts. Those 70 lines get about 15 pixels each at full screen, and about 8 in a half-height player. Nobody reads that.

The fix takes a minute. Un-maximise the editor and size the window to 1920 by 1080, so a 1080p recording captures it pixel for pixel with no shrinking. Then zoom the editor two steps until about 30 lines fill the height. Each line now gets about 36 pixels at full screen and 18 in a small player, which is comfortable. Same monitor, same font, same code; the only change is how much of it is in the frame.

If your walkthrough needs the editor and a browser, record the entire screen, but first close everything else, mute notifications and move to a single monitor. The post on screen recording settings covers resolution and frame rate in more depth, and how to screen record on Chrome covers the share dialog itself.

Pick a theme and font that survive compression

Video compression is hard on thin, coloured text. Most common video formats store colour at a lower resolution than brightness, so text whose readability depends on colour (dark red on black, blue on dark grey) blurs before text that differs mainly in brightness. Themes that look elegant on your screen can fall apart on video.

What works:

• Strong contrast, including comments. Many popular dark themes render comments in a dim grey that is already hard to read on a laptop. The accessibility guideline for text contrast is at least 4.5 to 1 for normal-size text (WCAG 2.1, contrast minimum); a theme whose comments meet that will survive a video player.
• Dark or light, as long as it is high contrast. Neither is inherently better. Light themes tend to compress cleanly; dark themes are fine if the text is bright enough. If you will share the video somewhere with a white page around it, a light theme looks less jarring.
• A clear monospace font at a regular or medium weight. Very thin weights disappear. Fonts that clearly distinguish 0 from O and 1 from l help viewers who cannot zoom in.
• Ligatures off. Ligatures that turn => into an arrow and !== into a single glyph look nice to people who know them and confuse people who do not, especially when they are trying to type what they see.
• No transparency or background images. A translucent terminal over a wallpaper is decoration that costs readability.

Clear the stage before you record

Everything on screen competes with the code for the viewer's attention and for pixels. A few minutes of tidying makes the code bigger and the recording calmer.

• Hide the sidebar, minimap and activity bar unless you are using them. VS Code's Zen Mode (Ctrl+K then Z, or Cmd+K then Z on a Mac) hides almost everything except the editor (VS Code docs); JetBrains has Distraction-free and Zen modes.
• Close unrelated tabs. Open the files you will show, in the order you will show them. Tab names are visible, and twenty open tabs tell the viewer nothing.
• Turn off notifications. Operating system, chat app and editor pop-ups. A message preview sliding in mid-explanation is distracting and sometimes private.
• Disable inline AI suggestions or noisy hovers if they pop up while you type. Ghost text that you then ignore confuses viewers about what is actually in the file.
• Collapse regions you are not discussing. Folding a long import block keeps the interesting part on screen.

Show keystrokes and point deliberately

If the lesson includes shortcuts (a refactoring command, a debugger step, a multi-cursor edit), viewers need to see what you pressed. Narrating "and now I press Control-Shift-R" is slow and easy to miss.

VS Code has a built-in Screencast Mode: run Developer: Toggle Screencast Mode from the Command Palette, and it shows your keystrokes and highlights mouse clicks. By default it shows every key; the screencastMode.onlyKeyboardShortcuts setting limits it to actual shortcuts, which is usually what you want, and other settings control its position and size (VS Code 1.38 release notes). JetBrains IDEs have the Presentation Assistant, which shows the name and shortcut of each action you use (JetBrains Guide).

For the mouse, two rules. First, move it to what you are talking about and then leave it still; a cursor drawing circles while you talk pulls the eye away from the code every time it moves. Second, select the lines you are explaining. A selection highlight is much easier to follow than a small pointer. VeoRec can add click highlights while recording, which helps when you are clicking through a UI or a debugger toolbar.

Make the terminal readable too

Terminals have their own problems on video: long prompts, walls of output that scroll past, and commands that run before the viewer has read them.

1. Shorten the prompt A prompt with user, host, full path, Git branch, Node version and the time can take half the line. Use something minimal for recording: in bash PS1='\W $ ', in zsh PROMPT='%1~ %# '. It also stops your username and machine name appearing in every frame.
2. Zoom the terminal separately if needed Most terminal apps zoom with Ctrl and + (Cmd and + on a Mac). If you use the integrated terminal and zoom the whole editor, it scales with everything else.
3. Make the panel tall enough A three-line terminal panel at the bottom of the editor will scroll output away before anyone reads it. Make it at least a third of the window when the terminal matters, or maximise it.
4. Clear before each command Ctrl+L or clear before an important command means the output starts at the top of a clean panel, and old output (which might include something private) is gone.
5. Type, pause, then press Enter Give viewers a beat to read the command before the output buries it. Saying the command aloud while it sits there unexecuted works well.
6. Trim long output Pipe through head or tail, use git --no-pager log -5 instead of the full log, or filter logs to the lines you care about. Three relevant lines beat three hundred.

If a command takes a long time, either pause the recording while it runs or say what is happening and cut the wait later. Trimming and cutting in the browser is quick; the editing guide covers trim, split and removing silences.

Keep secrets out of the frame

The terminal is the most likely place for a secret to appear in a developer recording, followed by config files and cloud consoles. The usual suspects:

• .env files and config files opened "just to show the structure".
• env, printenv or export output, which prints every variable in the shell.
• Shell history: pressing the up arrow or Ctrl+R can bring back an old command with a token in it.
• Git remotes with credentials embedded in the URL, shown by git remote -v.
• Container and cluster tooling that prints environment variables, such as docker inspect or kubectl describe.
• Browser devtools showing cookies, local storage or an Authorization header in the network panel.
• Autocomplete dropdowns that suggest a previous value, including tokens.

Before recording, switch to a dummy environment file and a fresh terminal. If you have to enter a real secret, read -s in bash or zsh reads input without echoing it to the screen. Note that keeping a command out of shell history (for example with bash's HISTCONTROL=ignorespace and a leading space, documented in the Bash manual) does nothing for the recording: the command is still on screen while you type it.

After recording, watch it once at normal speed before sharing, specifically looking for secrets. If something slipped through, blur it. In VeoRec you draw a blur box over the area in the browser editor and render to apply it; the demo below shows the idea.

Choose resolution and frame rate for code

For code, 1080p is the sensible ceiling and usually the right choice. It gives enough pixels for 25 to 35 lines to be sharp, and it is what most viewers can display anyway. VeoRec records up to 1080p. Recording at 4K mostly produces larger files that are scaled back down for nearly every viewer; it is far more effective to zoom the editor so fewer lines fill the same frame.

Frame rate matters less for code than for anything else. Text that sits still for seconds at a time does not need 60 frames per second; 30 is plenty, and some recorders go lower for static content. Smooth scrolling looks a bit nicer at higher frame rates, but scrolling is exactly what you should be doing less of. If your recorder lets you choose, the estimator below shows how resolution and frame rate change the size of a typical walkthrough:

Smaller files matter if you upload the video somewhere with a size limit. GitHub, for example, lists a 10 MB limit for videos attached on free plans at the time of writing (GitHub docs). A share link sidesteps that, which is one reason teams link walkthroughs in pull requests instead of uploading them, a habit covered in code review with video; explaining a pull request with video covers the rest of that workflow.

Run the pre-recording checklist

The first time, this takes ten minutes. With a recording profile set up, it takes two. Tick through it before you press record; it remembers your progress in this browser.

What to do before your next recording

Set up a recording profile once: zoom level, theme, font without ligatures, minimap off, short prompt. Then record thirty seconds of a real file, open the result in a small player window (about the size of a chat preview) and see if you can read every line. If you cannot, zoom one more step and try again. That single test tells you more than any rule of thumb.

After that, the habits are what count: one function on screen at a time, the cursor still, the terminal cleared, and one full watch-through for secrets before you share. If you want a recorder that handles the sharing part for you, VeoRec's Chrome screen recorder records a tab, a window or the whole screen from Chrome and copies the link as soon as you stop.