ShareX Screen Recording Has Low FPS: How to Fix Choppy Video

If a ShareX screen recording has low FPS, the finished video may look choppy, skip motion, or play less smoothly than the activity you saw on screen. The cause usually falls into one of four categories: the recording workload exceeds what the encoder can process, ShareX is configured for an unsuitable frame rate or encoder preset, the destination cannot accept data quickly enough, or the video is being recorded or played in a workflow that introduces its own limitations. GIF recording is a separate case because GIF is not designed to reproduce smooth, high-quality video efficiently.

The quickest solution is not to change every available option. First reproduce the problem with a short controlled test, then adjust the recording region, frame rate, encoder load, and save location one factor at a time. After each adjustment, check whether the output maintains even motion. Once a test succeeds at settings that meet your real needs, stop changing settings.

1. Confirm the Symptom and Reproduce It With a Simple Test

Before treating this as a ShareX troubleshooting problem, confirm where the choppiness appears. A video can contain genuinely uneven frame capture, but it can also be recorded correctly and then play badly in a particular media player, browser, editor, remote session, or network location.

1.1 Record a short, predictable motion test

Create a 10 to 15-second recording of a small region containing predictable movement. For example, drag a window slowly from side to side, scroll a simple webpage at a steady rate, or move the pointer in circles. Avoid testing with a game, streaming video, animated wallpaper, or full-screen high-resolution display at first. Those workloads add variables that make diagnosis harder.

Save the recording to a local folder on an internal drive. Play it in a normal local media player, not through a browser upload preview or directly from a network share. Success means the pointer, scrolling, or moving window progresses evenly without obvious freezes or large jumps.

1.2 Distinguish low capture FPS from playback trouble

Try the same file in a second media player. If it is smooth in one player but choppy in another, ShareX probably captured the video correctly. The issue is then decoding, hardware acceleration, player configuration, or the environment in which the file is being previewed.

Also copy a problematic file from any network, cloud-synchronized, or removable location to the internal drive before playing it. If local playback is smooth, the recording itself may be fine. Stop modifying ShareX in that case and troubleshoot the player or storage path instead.

1.3 Separate video recording from GIF recording

Confirm that you are evaluating an actual video file rather than an animated GIF. GIF has a limited color palette, produces large files for long or detailed motion, and is generally unsuitable for smooth full-screen recordings. Optimization steps may also remove or combine frames. A GIF that looks uneven does not automatically show that normal video capture is failing.

Use a video format for software demonstrations, scrolling pages, games, video playback, or any recording where motion quality matters. Reserve GIF for short, compact demonstrations with a small region, limited colors, and modest motion. If video is smooth but GIF is not, the practical fix is usually to deliver video rather than force GIF to behave like a modern video format.

2. Check the ShareX Settings Directly Related to Low FPS

ShareX uses FFmpeg for screen recording. The available recording options can vary with the selected source and encoder, but the central tradeoff remains the same: more pixels, more frames, and more complex compression require more processing. A requested FPS value is a target, not a guarantee that the computer can capture and encode every frame on time.

2.1 Reduce the recording region size

Region size is often the most effective setting to change. Recording a 3840 by 2160 desktop processes four times as many pixels per frame as recording 1920 by 1080. A large high-DPI desktop or multiple-monitor area can therefore become difficult even when the content appears visually simple.

Repeat the controlled test using a region around 1280 by 720 or just the application window that matters. Do not record empty desktop space, a second monitor, or browser chrome unless it is needed. If the smaller recording becomes smooth, the original pixel workload was too high.

At that point, choose one of these sustainable approaches:

• Record only the relevant window or application panel.
• Resize the application before recording it.
• Use a lower display resolution temporarily when the entire desktop must be shown.
• Record one monitor instead of a combined multi-monitor canvas.
• Use a dedicated recorder if full-resolution, high-frame-rate capture is essential.

Success means the chosen region can be recorded repeatedly without skipped motion. Once the region includes everything viewers need and the result is smooth, do not increase it merely because more screen area is available.

2.2 Set a realistic FPS target

A higher configured FPS does not repair a system that cannot encode frames quickly enough. Raising the target from 30 to 60 FPS doubles the number of frames the recorder attempts to process. For ordinary tutorials, application walkthroughs, and cursor-based demonstrations, 30 FPS is often a practical starting point. Lower rates may work for mostly static instructions, while 60 FPS is more appropriate for fast movement when the hardware and workflow can sustain it.

Run identical tests at 30 FPS and your higher target. If 30 FPS is smooth but 60 FPS is uneven, ShareX is functioning, but the higher workload is beyond the current configuration. Keep 30 FPS, reduce the region or encoder load, or move the job to a tool and encoder designed for higher-performance capture.

The meaningful measurement is the smoothness and timing of the output, not the number typed into a settings box. Stop increasing FPS when the result already looks smooth for the content being recorded.

2.3 Use a faster encoder preset when CPU load is high

Video encoders commonly offer presets that trade compression efficiency for encoding speed. A slower preset may produce a smaller file or better compression at a given quality, but it requires more processing during recording. If the CPU cannot finish frames in real time, motion may become uneven.

Select a faster preset for a temporary test. Keep the region and FPS unchanged so that the preset is the only meaningful variable. Watch CPU usage in Windows Task Manager during capture. If usage remains near its limit and the recording stutters, reduce the workload further.

A successful preset change produces smooth output without unacceptable image degradation or excessive file size. Once you find the fastest practical combination that records reliably, stop moving toward slower presets unless a controlled test proves that sufficient processing capacity remains.

2.4 Avoid changing unrelated capture options

Image effects, upload destinations, naming patterns, and post-capture actions usually do not determine the frame rate while frames are being captured. Disable complex post-recording automation during diagnosis if it launches heavy programs, but prioritize the settings that directly affect capture: region dimensions, FPS, encoder, preset, and output location.

3. Check Windows, Display, Storage, and Workflow Factors

Even appropriate ShareX settings can produce a poor result when another process competes for CPU, graphics, memory, or disk access. Check system behavior while the problem is happening rather than relying only on idle measurements.

3.1 Close applications that compete for resources

Browsers with many tabs, video editors, games, virtual machines, antivirus scans, synchronization clients, development builds, and conferencing software can consume resources needed for recording. Open Task Manager, start the controlled recording, and observe CPU, memory, GPU, and disk activity.

Close unnecessary heavy applications and repeat the same test. Do not close the application being demonstrated, essential security services, or unfamiliar Windows processes. Success means resource usage falls and the repeated recording becomes consistently smooth. If closing one application fixes the problem, schedule recording separately from that workload or reduce capture settings when both must run.

3.2 Account for high-DPI and multi-monitor displays

Windows scaling makes interface elements easier to read, but it does not necessarily reduce the number of physical pixels being captured. A 4K screen at 150 percent scaling is still a high-pixel-count recording source. Mixed-resolution or mixed-refresh-rate monitors can also create a more complicated desktop capture environment.

Test one monitor, one application, or a smaller region. If necessary, temporarily lower the display resolution for a full-desktop tutorial. The objective is not to disable high-DPI support permanently. It is to determine whether the physical capture dimensions are the limiting factor.

3.3 Treat games and video playback as demanding sources

Recording a game, high-frame-rate animation, or video playback is substantially more demanding than recording a mostly static desktop. The source application may already use most available CPU or GPU capacity. Screen capture then competes with the content being captured.

Reduce the game's graphics settings or frame-rate limit, lower the recording region and FPS, and test again. For protected streaming video, capture may also be blocked or show a blank image because of content protection. That is not a low-FPS setting problem.

If your actual requirement is smooth gameplay capture, high-refresh-rate recording, separate audio tracks, or reliable hardware-accelerated encoding, a dedicated recorder is generally the more appropriate tool. ShareX is especially convenient for screenshots, short desktop demonstrations, uploads, OCR, hotkeys, and automated capture workflows. Choosing a specialized recorder for sustained high-motion capture is a workflow decision, not evidence that ShareX is broken.

3.4 Save to a fast local destination

The encoder must write its output while recording. Slow removable drives, congested hard disks, network shares, remote folders, and heavily synchronized cloud directories can delay that work. Low free space can also cause failures or unpredictable behavior.

Temporarily choose a simple folder on a fast internal drive with adequate free space. Pause nonessential synchronization and avoid recording directly to a network destination. Record the same test and compare it with the original.

Success means local recording is smooth and completes normally. If so, keep the local folder as the recording destination, then copy or upload the finished file afterward. This separates time-sensitive capture from slower distribution tasks.

3.5 Test audio only when it is relevant

Audio configuration is not usually the first explanation for visibly low FPS, but device problems can complicate a recording workflow. If the issue began after changing microphones, virtual audio devices, or system-audio capture, make one short test without audio and another with the intended audio source.

If video becomes smooth only when audio is disabled, check the selected device, reconnect it, close applications holding the device, and verify that the expected input is available in Windows. If audio makes no difference, restore the required source and focus on region, FPS, encoding, and storage.

3.6 Check permissions and security software when capture fails

Permissions are more likely to cause missing frames, black output, an inability to capture a particular elevated window, or a failed recording than consistently low FPS. If ShareX is not working only with an administrator-level application, test ShareX with equivalent elevation where appropriate. If security software blocks FFmpeg or prevents output files from being created, review its alerts rather than adding broad exclusions without evidence.

4. Run a Clean Temporary Test With Minimal ShareX Settings

A clean test establishes whether the basic recording path works. It should be temporary and simple, not a complete redesign of your normal ShareX setup.

1. Choose video recording rather than GIF recording.
2. Select a small region around a simple application window.
3. Set a moderate target such as 30 FPS.
4. Use a faster encoder preset if one is available in the selected configuration.
5. Save to a local folder on an internal drive.
6. Disable unnecessary post-capture uploads, conversions, or application launches for the test.
7. Close heavy background applications.
8. Record 10 to 15 seconds of steady scrolling or window movement.
9. Play the file locally in two media players.

If this clean recording is smooth, add your normal requirements back one at a time. Increase the region first, then test. Add audio, then test. Increase FPS only if necessary, then test. Restore automation last. The first change that brings the choppiness back identifies the practical limit or conflicting workflow step.

If the minimal recording is still choppy, verify that FFmpeg is available to ShareX, check current resource usage, try another local destination, and restart Windows before repeating the test. A restart is useful here because it clears stuck processes and pending resource contention, not because restarting is a universal cure.

5. Check Task History, Logs, and Recent Output

ShareX task history can help determine whether the recording completed, where the file was saved, and whether later workflow actions failed. Open the most recent output directly from history when possible and verify that you are reviewing the latest test rather than an older file with similar naming.

Look for explicit FFmpeg errors, missing encoder messages, permission failures, unavailable devices, write errors, or output files that are unexpectedly small. An error at the end of recording may indicate that the capture did not finalize correctly. A successful recording followed by a failed upload is a separate problem and should not be diagnosed as low capture FPS.

Compare recent files by duration, dimensions, and size. If a 15-second test unexpectedly lasts longer or shorter than the action recorded, timing may be affected. If the file has the expected duration but looks rough only in one preview tool, investigate playback. If small-region recordings work while large ones consistently become uneven, the evidence points back to processing load.

When asking for help, record the selected region dimensions, configured FPS, encoder and preset, output format, save location type, display resolution, and whether the source was a desktop application, game, or playing video. Include the exact error text if one exists. This is more useful than reporting only that ShareX is not working.

6. Quick Fix Checklist

• Confirm the output is video, not an animated GIF.
• Play the file locally in a second media player.
• Record a small region instead of the full high-DPI desktop.
• Start at 30 FPS rather than assuming 60 FPS will be smoother.
• Choose a faster encoder preset when CPU usage is high.
• Close games, editors, browser tabs, virtual machines, and background scans.
• Save to an internal drive with adequate free space.
• Avoid recording directly to a network, removable, or synchronized destination.
• Test without audio only if an audio-device change may be involved.
• Add normal workflow steps back one at a time after a successful clean test.
• Use a dedicated recorder for sustained high-resolution or high-frame-rate gameplay capture.

The best stopping point is the first configuration that repeatedly records your real content smoothly at acceptable quality. Do not keep raising FPS, enlarging the region, or selecting slower encoding merely to maximize settings. Reliable output is the goal.

7. Frequently Asked Questions

7.1 Why does setting ShareX to 60 FPS not produce smooth 60 FPS video?

The FPS field expresses the requested capture rate. The computer must still capture, process, encode, and write each frame before the next one is due. If the region is too large or the CPU, GPU, or drive is overloaded, the actual result can be uneven. Test 30 FPS with a smaller region. If it is smooth, increase only one setting at a time.

7.2 Why is a small ShareX recording smooth but full screen is choppy?

A full-screen recording contains more pixels per frame. This difference is especially large on 4K, ultrawide, high-DPI, or multi-monitor desktops. The successful small test shows that the basic recording pipeline works. Reduce the full-screen resolution, capture only the relevant window, lower FPS, or use faster encoding.

7.3 Can a slow drive cause ShareX screen recording low FPS?

Yes, storage can contribute when the output destination cannot accept data consistently. Network shares, slow removable media, busy hard disks, nearly full drives, and cloud-synchronized folders are common suspects. Record to a fast internal drive, then copy or upload the completed file.

7.4 Why does the ShareX recording look choppy only after uploading?

The hosting service may create a lower-frame-rate preview, transcode the file, or stream it poorly over the current connection. Download the uploaded file and compare it with the local original. If the original is smooth, changing ShareX capture settings is unlikely to help. Investigate the platform's processing and playback behavior.

7.5 Is ShareX suitable for recording games?

ShareX can capture screen activity, but demanding games require sustained high-speed capture and often benefit from game-specific capture methods and hardware encoding. For occasional clips, reducing the region, game load, and recording FPS may be enough. For regular gameplay, high refresh rates, or advanced audio routing, use a dedicated recorder.

7.6 Should I reinstall ShareX if recordings are choppy?

Reinstallation is not the first step because low FPS is more commonly related to workload, settings, storage, or playback. First complete the small-region local test, lower the FPS, try a faster preset, and check resource usage. Consider repairing or reinstalling only when FFmpeg components are missing, recording options fail to initialize, files cannot be produced, or configuration problems persist after controlled tests.