Screen recording settings explained: resolution, frame rate and bitrate

Resolution decides how sharp text can be, frame rate how smooth motion looks, and bitrate how much of either survives compression. This guide covers what each one does to a work recording, with the file size arithmetic written out.

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

Screen recording settings come down to four numbers: resolution, frame rate, bitrate and the file size they produce. Most recorders hide some of them behind a quality menu, but the trade-offs are the same everywhere. Get them right and a code walkthrough stays readable at small sizes; get them wrong and you either ship a 2 GB file for a five-minute update or a video where every scroll turns to mush.

This guide explains what each setting does to a work recording (code, designs, product demos, bug reports), shows the arithmetic for file size, and ends with defaults you can copy.

Four numbers, one relationship

• Resolution is how many pixels each frame has, written as height: 720p is 1280 by 720, 1080p is 1920 by 1080, 1440p is 2560 by 1440, 2160p (4K) is 3840 by 2160.
• Frame rate is how many frames per second (fps) are captured. 30 and 60 are the usual choices.
• Bitrate is how much data the encoder may spend per second of video, usually in megabits per second (Mbps). It is the budget that pixels and frames have to share.
• File size is the result: bitrate multiplied by duration.

The relationship that matters is between the first three. Raising resolution or frame rate gives the encoder more to describe; if the bitrate stays the same, each frame gets less data and quality drops. That is why a 4K, 60 fps recording at a low bitrate can look worse than a 1080p, 30 fps one at the same bitrate.

Screen content is unusual video. Most of the frame sits still for seconds at a time, and modern codecs only spend data on what changes. A slide that does not move costs almost nothing. A fast scroll through a long page, where every pixel changes every frame, costs a lot. Keep that in mind: the settings that look fine on a static screen are tested by motion.

Resolution: record at the size people will watch

The resolution of a screen recording starts with what you share. A Chrome tab is captured at the tab's size; a window at the window's size; the entire screen at the monitor's size. The recorder may then scale the result to a maximum, such as 1080p.

Then the viewer's player scales it again. Most work videos are watched in a panel next to a ticket, a chat thread or an email, maybe 800 to 1200 pixels wide, often less. A 1080p recording shown 960 pixels wide is already being halved. A 4K recording shown at the same size is being quartered.

That is the trap with big monitors. Record a 2560 by 1440 screen and scale it to 1080p, and every element shrinks to 75 percent of its size before the player shrinks it again. Your 13-pixel body text becomes roughly 10 pixels in the file and smaller still on screen. More resolution in the source does not fix this; bigger text does.

Shape matters as much as size. Most players are 16:9. Record an ultrawide monitor and the video arrives as a thin strip with black bars above and below, every element tiny. Record a tall, narrow window and you get bars at the sides. Sizing the shared window close to 16:9 fills the player and keeps text as large as it can be.

For most work, 1080p is the sweet spot. It is large enough for real detail, small enough to upload quickly, and it matches how people watch. 720p is fine for talking-head updates with a little screen, and for slow connections. Go above 1080p only when viewers will genuinely watch full screen on large displays, such as a design review of pixel-level detail.

Frame rate: 30 for screens, 60 for motion

Film uses 24 fps, TV and most web video 25 or 30, games and smooth scrolling 60. For screen recordings the question is simple: how much of what you show moves quickly?

• 30 fps handles a moving cursor, typing, page loads and normal scrolling without anyone noticing. It is the right default for walkthroughs, bug reports, code and slides.
• 60 fps is worth it for animation work (a designer reviewing a transition or a micro-interaction), for showing scroll-linked effects, and for games. The motion looks visibly smoother.
• 15 fps or less saves space but makes the cursor jump and scrolling stutter. Avoid it unless the screen is close to static, like a slide deck.

Doubling the frame rate does not double the file, because consecutive frames of a screen are often nearly identical. But it does need more bitrate to keep each frame clean during motion. YouTube's recommended upload bitrates show the pattern: 8 Mbps for 1080p at 24 to 30 fps, and 12 Mbps for 1080p at 48 to 60 fps. Those figures are for general video, which is busier than most screens, but the ratio is a useful guide.

Bitrate: the setting that decides quality

If your recorder lets you set only one thing, bitrate is the one with the most effect. It decides how much detail survives compression when the screen changes.

You rarely see low bitrate on a still frame. You see it when the screen moves: text smears into blocks for half a second after a scroll, colour gradients turn into bands, and a page transition looks like it is melting. Then the frame settles and looks fine again. If your recordings look sharp when paused but ugly while scrolling, bitrate is the cause.

Browsers have defaults when a recorder does not choose. MDN's MediaRecorder page notes that if no bitrate is specified, the browser picks 2.5 Mbps or 10 Mbps for video depending on the browser. That is a wide range, which is one reason the same 1080p setting can produce very different quality in two tools.

Some encoders can also be told what kind of content they are getting. The browser's contentHint property, documented on MDN, lets a recorder mark a screen as detail or text (keep edges sharp, accept lower frame rate under pressure) or as motion (keep movement smooth, accept softer detail). You will not set this yourself, but it explains why one tool keeps code crisp while another keeps animation smooth: they are making different trade-offs with the same bits.

These ranges are deliberately below YouTube's general-video recommendations, because screens are calmer than camera footage. Treat them as a starting point and test with your own content.

A twenty-second test that settles the question

Open the densest thing you record: a long pull request diff, a spreadsheet with a hundred rows, a settings page full of small labels. Record twenty seconds: five still, ten of steady scrolling with the mouse wheel, five still again. Play it back at full size and pause halfway through the scroll.

If you can read a line of code or a cell value on the paused frame, the bitrate is enough for everything calmer than that. If the paused frame is a field of grey blocks that snaps into focus a moment after the scroll stops, it is not. Raise the bitrate one step (or the quality setting, if that is all your tool exposes) and run it again. When the test passes, you never need to think about it for that tool and monitor again.

One mistake to avoid while testing: judging the result in a tiny preview thumbnail. Small previews hide smearing. Look at the file the way your most demanding viewer will, which for code reviews usually means full screen on a laptop.

File size: do the arithmetic once

File size is bitrate times time, divided by eight to turn bits into bytes. At 4 Mbps, one minute is 4 × 60 = 240 megabits, which is 30 megabytes. Ten minutes is about 300 MB. At 8 Mbps it is 60 MB a minute and 600 MB for ten minutes.

Real files come out smaller when the encoder uses a variable bitrate and the screen is calm, and roughly at the limit when the screen is busy. Audio adds a little: voice at 128 kilobits per second is about 1 MB a minute. Play with the numbers for your own recordings here.

Why care? Three reasons. Upload time: a 600 MB file on a 10 Mbps uplink takes about eight minutes. Storage: if your recordings average 150 MB, a 5 GB allowance holds about 33 of them. And attachment limits: many email and chat tools refuse files over a few dozen megabytes, which is why work recordings are usually shared as links rather than attachments.

If a tool uploads while you record, upload speed also sets a ceiling. When the bitrate is higher than your uplink, the upload falls behind and keeps going after you press stop. On a typical home connection with a few megabits up, a 4 to 6 Mbps recording keeps pace; a 20 Mbps one will not.

Screen recording settings for code, design, demos and bug reports

Settings follow content. These are the defaults we would hand a team for the five recordings they make most often.

Notice the last column. The things that make the biggest difference to readability (font size, zoom, a clean demo account) are not recorder settings at all. For an editor-specific setup, see recording your IDE and terminal; for the share dialog choices themselves, see how to screen record on Chrome.

Audio settings that matter for voice

Audio is a small part of the file and a large part of whether people keep watching. Viewers forgive soft video far sooner than muddy or clipped sound.

• Sample rate: 48 kHz is the standard for video and what most browsers and cameras use. You rarely need to change it.
• Mono or stereo: a single voice is effectively mono. Stereo matters only when the recording includes music or audio where left and right carry different sound.
• Bitrate: voice sounds clean at a fraction of what music needs. If a tool offers an audio quality choice, the middle setting is usually plenty for speech.
• Levels: far more important than any number. Speak at a normal volume with the mic close, and keep any page or system sound well below your voice.

If your voice sounds bad, the fix is almost never a setting. It is microphone distance, the room and the device; see how to sound good on recordings.

Formats: WebM, MP4 and why it rarely matters now

Recorders that run in the browser usually produce WebM, an open format that every major browser plays. ChromeOS's own Screen capture tool also saves video as .webm files, as Google's Chromebook help notes, while macOS saves .mov from its Screenshot tool. MP4 with H.264 video is the most widely compatible format for editing software, older players and some upload forms.

If you share a link, the format barely matters: the service converts and streams the video in a form the viewer's browser can play. It matters when you download a file to edit in desktop software, attach it to a system that only accepts MP4, or archive it. Check the export options of your tool before you need them.

One quirk to know: screen recordings are often variable frame rate, meaning the recorder writes a new frame only when something changes. That is efficient, but some desktop editors handle it badly, drifting the audio out of sync. If you edit in a desktop tool and see drift, convert to a constant frame rate first.

What you can fix afterwards, and what you cannot

Settings feel less stressful once you know which mistakes are recoverable. The rule is simple: you can always throw information away later, but you cannot add back what was never recorded.

• Too big a file? Fixable. Re-encoding at a lower bitrate or resolution shrinks it, with a small loss of quality.
• Too long? Fixable. Trimming the start and end, or cutting out a dead section, does not touch the quality of what remains.
• Text too small? Only partly fixable. Cropping in on part of the frame enlarges it, but the cropped area has fewer pixels, so it gets softer the more you zoom.
• Smeared scrolling from low bitrate? Not fixable. The detail was discarded when the video was encoded. Re-record that part.
• Choppy motion from a low frame rate? Not fixable. Missing frames cannot be invented without artefacts.
• A password or customer email visible? Fixable with a blur box over that area for the frames where it shows.

That list suggests where to be generous and where to be careful. Be generous with bitrate and frame rate when motion matters, because those cannot be repaired. Be relaxed about length and file size, because an editor handles both. VeoRec's browser editor, for instance, can trim, split, cut and remove silences, and put blur boxes over secrets, which are applied when the video is rendered.

Diagnose four real recording problems

Four situations that come up in real teams. Pick the change you would make.

Defaults to copy, and what to do next

If you want one set of defaults for nearly everything: share the narrowest thing that shows what you need, zoom the content so text is large, record at 1080p and 30 fps, and let the bitrate land somewhere around 4 to 6 Mbps. Switch to 60 fps for motion reviews. Record a 20-second scroll test whenever you change tools or monitors.

Many recorders make these choices for you. VeoRec, for example, records up to 1080p and uploads as you record, so the useful decisions left to you are the ones in the last column of the table above: what to share, how big the text is and what is on screen. On the Free plan recordings run up to 10 minutes with 5 GB of storage, and Pro raises that to recordings up to 10 hours and 1 TB (see VeoRec's plans and limits).

Then put the settings to work. The screen recording tips post covers preparing the screen, pacing and endings, which affect how a recording is received far more than one extra megabit per second.