ShareX Duplicate Files Overwriting Old Captures: How to Stop It

When a new ShareX screenshot or recording replaces an older capture, the problem is usually a filename collision rather than a failed save. ShareX is successfully writing the new file, but the generated name matches a file that already exists in the destination folder. Confusing duplicates can arise from the same underlying issue, particularly when ShareX, Windows, or a cloud-sync service responds to collisions by adding counters or conflict labels.

The most likely causes are a filename pattern without enough uniqueness, timestamps that are too coarse, a fixed filename entered manually, a duplicate counter that resets or is missing, or multiple workflows writing similar names into one folder. Before changing anything, back up the affected capture folder. Testing overwrite behavior against irreplaceable files is unnecessary and risky.

1. How Do You Confirm That Filenames Are Colliding?

First, separate overwriting from other ShareX problems. A save-path problem usually sends files to an unexpected folder or prevents them from being saved. A filename collision produces a different symptom: the expected folder contains a file, but its contents or modified time change after another capture.

1.1 Run a controlled capture test

Create a temporary folder outside your normal screenshot archive and cloud-sync folders. Copy any important captures elsewhere before testing. Then use the ShareX workflow that appears to cause the problem.

1. Open the destination folder in File Explorer.
2. Take one screenshot and note its exact filename, file size, and modified time.
3. Wait a few seconds, change something visible on the screen, and take another screenshot with the same hotkey.
4. Refresh File Explorer and compare the filenames, previews, file count, and modified times.
5. Repeat the test with a screen recording if recordings are also affected.

A confirmed collision has a clear signature. The folder contains the same number of files after the second capture, while an existing file receives a newer modified time or different content. Alternatively, a second file appears with an automatically added suffix such as a number, copy label, or sync-conflict marker.

If every test creates a distinctly named file and the old files remain unchanged, stop changing filename settings. The original incident may involve another workflow, another destination folder, or a cloud-sync conflict rather than ShareX overwriting locally.

1.2 Identify which workflow causes the collision

Test each relevant action separately. A region screenshot, full-screen screenshot, scrolling capture, screen recording, GIF recording, image-editor save, and upload-after-capture workflow may not all use the same naming or destination behavior.

Also check whether two ShareX hotkeys run different task configurations while writing into the same output folder. For example, a full-screen hotkey and a region-capture hotkey may both create a name based only on the current date. If used on the same day, they can request identical names even though the capture actions differ.

2. Check the ShareX Settings Directly Related to This Problem

The names and locations of ShareX options can vary as the application evolves, so focus on the purpose of each setting rather than expecting one exact menu label. Review the filename pattern, destination folder, task-specific settings, and any counter or timestamp components used by the affected workflow.

2.1 Make the filename pattern unique

A safe capture name needs a component that changes for every file. A date alone is not sufficiently unique. A pattern representing only the year, month, and day can produce the same requested filename throughout that day. Adding a time improves uniqueness, while adding finer time precision or a duplicate counter makes rapid captures safer.

Useful conceptual patterns include:

• A capture label followed by the full date and time
• The date, time, and a duplicate counter
• The workflow type, date, time, and counter
• A project label followed by a high-precision timestamp

For example, names conceptually resembling Screenshot_2026-04-18_14-32-09 are safer than Screenshot_2026-04-18. If you regularly take several captures within one second, use finer timestamp precision when supported or include a duplicate counter. Consult the variable or pattern help displayed by your installed ShareX build instead of copying unverified placeholder syntax.

After changing the pattern, take several rapid captures. Success means every capture receives a distinct name and all earlier files remain intact. Once that happens, stop adjusting the pattern.

2.2 Check date-time precision

A filename can include a timestamp and still collide. If the time portion records only hours and minutes, every capture taken within the same minute may request the same name. Even second-level precision can be insufficient for rapid hotkey sequences, automated captures, or workflows that generate multiple outputs almost simultaneously.

Increase the precision enough for your real capture frequency. For occasional manual screenshots, seconds plus a collision counter are generally practical. For automated or burst workflows, use the finest supported time component together with a counter. The counter is valuable because timing alone cannot guarantee uniqueness when multiple tasks start at nearly the same instant.

2.3 Verify duplicate counter behavior

A duplicate counter allows a base name to remain readable while distinguishing repeated names. The resulting files might conceptually look like Capture_2026-04-18_14-32-09, Capture_2026-04-18_14-32-09_1, and Capture_2026-04-18_14-32-09_2.

Confirm that the pattern actually contains the supported counter variable and that the affected task uses that pattern. Do not assume a counter shown in one configuration applies to every hotkey or recording action. Test with several captures in quick succession. Success is a growing file count with predictable suffixes and no changes to the contents of earlier files.

2.4 Remove manual fixed filenames

A fixed name such as screenshot.png, latest.png, or recording.mp4 is appropriate only when replacement is intentional. It is unsafe for an archive. Fixed names can appear in after-capture actions, custom workflows, command-line arguments, image-editor saves, custom uploaders, or prompts where the same name is repeatedly accepted.

Replace the fixed value with a generated unique name, or save deliberate single-file outputs in a separate folder clearly labeled as replaceable. If you need both an archive and a continuously updated file, keep uniquely named originals and create the replaceable copy as a separate automation step.

2.5 Review screenshots and recordings separately

Do not assume the screenshot fix automatically protects recordings. Screen recording may use a different output extension, destination, naming pattern, or task configuration. Screenshots and recordings can also share a base name without colliding when their extensions differ, but later conversion or processing may cause two outputs to target the same extension and filename.

Run separate tests for screenshots, GIF recordings, and video recordings. A successful configuration preserves every output from each workflow, even when the actions are launched close together.

3. Check Windows, Destination, and Workflow Factors

If the filename pattern appears unique, investigate what happens after ShareX creates the file. File Explorer, cloud-sync software, post-processing tools, and multiple hotkeys can make a collision look inconsistent.

3.1 Check hotkeys and task-specific destinations

Review the hotkeys you actually press, not only the default capture configuration. Two hotkeys may use separate task settings but write into the same folder. If both generate generic names, their outputs can collide.

You can resolve this in either of two ways:

• Give every workflow a globally unique filename containing enough time precision and a counter.
• Place different workflows in separate folders, such as Screenshots, Recordings, OCR, and Edited.

Separate folders improve organization, but they are not a substitute for unique names. Repeated screenshot names can still collide inside the Screenshots folder.

3.2 Look for cloud-sync conflict behavior

OneDrive, Dropbox, Google Drive, and similar services monitor synchronized folders and reconcile changes from multiple devices. If two devices or processes create the same path, the sync client may preserve both by renaming one as a copy or conflict. It may also restore a remote version, making a locally replaced file appear to change again.

Pause synchronization temporarily and repeat the test in a new local folder that is not synchronized. If unique files remain intact there, ShareX may be generating files correctly while the sync workflow introduces duplicates or conflicts. Re-enable synchronization only after confirming unique naming. Then test a disposable synced folder before returning to the main archive.

3.3 Check permissions only when the evidence supports it

Permissions are not the first suspect when an existing file is visibly replaced. However, controlled-folder protection, security software, or restricted directories can alter how an application writes temporary and final files. Use a normal user-owned test folder, such as a new folder under Pictures, to eliminate those variables.

If the local test works, compare the permissions and security controls on the original destination. Do not disable security software broadly. Add an exception only when logs or notifications identify a specific block and you understand the consequences.

3.4 Inspect post-capture automation

ShareX can run actions after capture, including editing, conversion, copying, uploading, or external commands. An external tool may save its result using a fixed name even though the original capture was unique. This is especially relevant when the apparent overwrite happens after an editor closes or after a recording is converted.

Temporarily disable nonessential after-capture and after-upload actions. Restore them one at a time, testing after each change. When the collision returns, inspect the most recently restored action for a fixed output name or shared destination.

4. Run a Clean Temporary Test With Minimal ShareX Settings

A minimal test separates the core capture operation from custom hotkeys, uploads, editors, scripts, and synchronized folders. It should be temporary and reversible.

1. Back up your ShareX configuration and important capture files using the options available in your installation.
2. Create a new local folder containing no existing files.
3. Choose a basic screenshot task with no upload, external command, editor, or conversion step.
4. Use a filename design containing a full date, time, and duplicate counter where supported.
5. Take five screenshots rapidly and verify that five files remain.
6. Repeat with a short recording using its own unique naming setup.

If the clean test succeeds, ShareX capture itself is working. Stop changing global or unrelated Windows settings. Reintroduce the original destination, hotkey configuration, and automation steps individually. The first restored component that recreates the collision is the useful lead.

If the clean test still overwrites files, record the exact generated names and check whether the pattern is being interpreted as expected. A name containing visible placeholder text may indicate an unsupported or incorrectly entered variable. Use the pattern guidance included in your installed application to select supported variables.

5. Check Task History, Modified Times, and Recent Output

ShareX task history can help determine what path and filename were associated with a recent operation. Compare history entries with the files currently present in the destination. If multiple tasks point to the same local path, you have strong evidence of a naming collision.

5.1 Compare task history with File Explorer

For each test capture, note the local filename shown by ShareX and then locate it in File Explorer. Enable file extensions and use the Details view so that names, types, sizes, and modified times are visible.

Look for these patterns:

• Several history entries resolving to one local path
• An existing file whose modified time matches the latest capture
• Different files with conflict, copy, or numbered suffixes
• A screenshot and converted output targeting the same final name
• History showing a different destination than the folder you were watching

The last item indicates a path misunderstanding, not overwrite behavior. If history shows that captures were saved elsewhere, investigate destination settings separately rather than continuing with collision fixes.

5.2 Review errors and logs in context

Logs are most useful when they show the exact path requested, an existing-file error, access denial, or failure in an external action. Save the relevant message and timestamp before changing settings. Avoid treating unrelated upload or network errors as proof of a local filename collision. A failed upload can occur after a screenshot was saved correctly.

If ShareX appears not to be working but the local file exists with a unique name, troubleshoot the failing stage separately. Capture, local save, editing, upload, and URL copying are distinct steps.

6. Quick Fix Checklist

• Back up the capture folder before deliberately testing overwrites.
• Confirm the symptom by comparing file count, content, and modified time.
• Replace date-only or fixed names with a unique date-time-based pattern.
• Add finer time precision for rapid or automated captures.
• Use a supported duplicate counter as a fallback against identical timestamps.
• Check the actual task settings assigned to each hotkey.
• Test screenshot and recording filenames separately.
• Separate workflows into folders when that improves clarity.
• Pause cloud sync and test in a new local folder.
• Disable post-capture automation temporarily, then restore actions individually.
• Compare ShareX task history with the local path and modified time.
• Stop changing settings as soon as repeated tests preserve every capture.

7. Frequently Asked Questions

7.1 Why does ShareX overwrite a file even though the name contains a date?

A date identifies a day, not an individual capture. Every screenshot taken on that date can request the same name. Add time with sufficient precision and a duplicate counter where supported. Test several rapid captures to verify that the complete generated name changes each time.

7.2 Is adding seconds to the filename enough?

It may be enough for occasional manual screenshots, but it is not guaranteed. Two hotkeys, automated captures, or multiple outputs can be generated within one second. Combining a timestamp with a collision counter is more robust than relying on time alone.

7.3 Why are duplicate files appearing instead of an old file being overwritten?

ShareX, Windows, another application, or a sync service may protect the existing file by adding a numerical or conflict suffix. This prevents data loss but indicates that more than one output requested the same base path. Correct the filename pattern rather than routinely deleting the resulting duplicates.

7.4 Can screenshots and screen recordings use the same folder safely?

Yes, provided every workflow generates unique names. Including the capture type in the name improves readability, while timestamps and counters prevent collisions. Test screenshots, videos, and GIFs independently because they may use different task settings or post-processing steps.

7.5 How can I tell whether cloud sync is responsible?

Pause the sync client and save several captures to a new local, unsynchronized folder. If every file remains unique locally but conflicts return in the synchronized folder, examine sync activity, multiple connected devices, and shared filenames. Keep the improved unique naming pattern even after resolving the sync issue.

7.6 When should I stop troubleshooting?

Stop when repeated screenshots and recordings each create a new file, older captures retain their original contents and modified times, and task history points to the expected paths. Do not continue changing unrelated display, audio, network, or permission settings after the affected workflow passes a realistic test.