ShareX Filename Pattern Not Working: How to Fix Names and Variables

When a ShareX filename pattern is not working, the capture may still save correctly but receive the wrong name, show a variable literally, omit expected information, create duplicates, or trigger an invalid path error. These symptoms usually come from one of five areas: incorrect pattern syntax, confusion between filename and folder rules, unsupported Windows characters, a task-specific override, or different settings being used for screenshots and recordings. The safest troubleshooting approach is to simplify the pattern, confirm which setting controls the current workflow, and add variables back one at a time.

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

Before editing several ShareX menus, identify exactly what is wrong. Filename troubleshooting is different from investigating a capture that never saves. This guide assumes the screenshot or recording exists, but its name or path is incorrect.

1.1 Identify the exact naming failure

Take a new screenshot and compare the resulting filename with the pattern you expected. Look for one of these specific symptoms:

• The filename uses ShareX's default naming format instead of your custom pattern.
• A variable appears as literal text rather than being replaced.
• Date or time values appear in the wrong position.
• The file contains a generic or incomplete name.
• Repeated captures create duplicate-name warnings or receive unexpected suffixes.
• The pattern works for screenshots but not screen recordings.
• ShareX reports an invalid filename or path.
• The file is placed in an unexpected subfolder.

Write down the exact output rather than relying on what you remember configuring. For example, note whether the saved file is named 2025-03-08_14-30-20.png, %project%.png, or Screenshot.png. Each result points to a different cause.

1.2 Test a plain filename first

Temporarily replace the custom pattern with a simple, path-safe word such as ShareXTest. Capture one screenshot through the same hotkey or workflow that produced the problem.

If the new file begins with or uses ShareXTest, you have confirmed that you are editing the setting used by that capture workflow. The original pattern, one of its variables, or its path characters is the likely cause. If the old name still appears, a task override or a different naming setting is controlling the output.

Success at this stage means the latest capture uses the simple test name. Once that happens, stop searching unrelated settings such as image quality, upload destinations, or capture-region options.

2. Check the ShareX Settings Directly Related to This Problem

2.1 Verify the filename pattern syntax and variables

ShareX uses recognized name-parser tokens to insert changing values into filenames. A token only works when it matches the syntax understood by ShareX. A descriptive placeholder invented for another application, such as {project} or %username%, should not be assumed to work unless ShareX offers it in the naming controls.

Open the ShareX task settings used by your workflow and locate the file-naming section. Use the variable or pattern menu presented by ShareX rather than typing tokens from memory. This is especially important when copying a pattern from an old forum post, another capture tool, or a computer with a different configuration.

A practical pattern-building sequence is:

1. Start with a fixed prefix such as Screenshot.
2. Add one supported year token using ShareX's variable menu.
3. Capture a test image and inspect the result.
4. Add the month and day tokens.
5. Test again before adding time, window-title, application, or counter information.

If a token appears literally in the resulting name, ShareX did not parse it in that context. Remove it and insert the corresponding variable through the application's menu. Success means every variable is replaced by a real value and no token syntax remains visible in the saved filename.

2.2 Check date and time tokens carefully

Date and time patterns are a common source of confusion because month and minute values need separate tokens. ShareX commonly represents date and time components with parser tokens such as year, month, day, hour, minute, and second. The exact token spelling matters. For example, a month token and a minute token cannot be swapped simply because both begin with the same letter.

Use separators that are legal in Windows filenames. Hyphens and underscores are dependable choices. A pattern conceptually structured as year-month-day_hour-minute-second is safer than a clock-style value containing colons.

Also consider whether the time is being evaluated when the task starts, when the capture finishes, or when a later workflow action runs. This distinction is usually irrelevant for screenshots but can be noticeable during long screen recordings. A recording started before midnight may receive values associated with a later stage of processing, depending on the active task and parser behavior.

Success means consecutive captures produce predictable date and time values in legal filename form. Once the output is correct, do not keep replacing tokens merely to make the pattern look different in the settings window.

2.3 Separate the folder path from the filename

A filename pattern should normally describe the file's base name, while ShareX's destination or screenshot-folder setting controls where the file is stored. Mixing the two can create unintended subfolders or invalid paths.

Windows interprets backslashes as folder separators. If you put a value such as Project\Screenshot into a field that permits path parsing, ShareX or Windows may treat Project as a directory rather than part of the filename. Conversely, adding a drive letter or full path to a filename-only field can introduce a colon and other unsupported structure.

Keep the first test unambiguous:

• Set the destination folder through ShareX's folder or path setting.
• Use only a base name and supported variables in the filename pattern.
• Do not append the file extension unless the relevant ShareX field explicitly expects it.
• Avoid leading or trailing spaces in both folder and filename fields.

Success means the file appears in the intended folder and its base name contains no accidental directory separators.

2.4 Look for capture profile and task overrides

ShareX can run different after-capture tasks, hotkey tasks, workflows, and task-specific configurations. A global pattern may appear to be ignored when the active hotkey uses an overridden task profile.

Test this by comparing two captures: one launched from the main ShareX capture menu and one launched with the problematic hotkey. If they receive different names, inspect the hotkey's task settings and any custom workflow attached to it. An override may intentionally use a separate naming pattern or destination.

Make one change at a time. Either remove the override so the workflow inherits the main settings, or edit the pattern inside the specific task configuration. Success means the menu capture and hotkey capture follow the naming rules you intended. They do not have to match if you deliberately want separate patterns.

2.5 Compare screenshot and recording patterns

Do not assume that an image capture and a screen recording pass through identical naming logic. They may use different output formats, recording options, task profiles, or post-processing steps. A screenshot pattern that works correctly does not prove that a recording workflow uses the same field.

Run one screenshot test and one short recording test. Check both entries in task history and compare their full saved paths. If only recordings are wrong, inspect screen-recording output settings, the selected encoder workflow, and any recording-specific task override. If only screenshots are wrong, stay within screenshot and image-task settings.

Success means each output type uses its intended pattern. Stop changing the working screenshot configuration once you have isolated the problem to recordings, and vice versa.

3. Check Windows and Workflow Factors That Affect Names

3.1 Remove invalid Windows filename characters

Windows reserves several characters for path and device syntax. A filename cannot normally contain the characters <, >, :, ", /, \, |, ?, or *. A variable can also introduce a forbidden character even when the visible pattern looks safe. Window titles, webpage titles, OCR results, and manually supplied labels are common sources.

For example, a window title containing a colon may be valid as on-screen text but unsafe when inserted directly into a Windows filename. Use ShareX's sanitization options when available, or avoid uncontrolled text variables in the filename. Prefer stable values such as dates, times, counters, and short fixed prefixes.

Windows also treats some names as reserved device names, and trailing spaces or periods can cause additional problems. Keep names reasonably short because the complete path includes the drive, folders, base filename, and extension.

Success means the same workflow can create several files without an invalid-name or invalid-path message. If replacing a title or OCR variable with a fixed word resolves the issue, the inserted text needs sanitization or should not be used in the pattern.

3.2 Understand duplicate-name handling

A fixed pattern such as Screenshot produces the same proposed name for every image of the same type. ShareX may add a suffix, apply duplicate-name handling, prompt, or follow another configured behavior. Unexpected suffixes therefore do not necessarily mean the pattern failed. They may be preventing an existing file from being overwritten.

Add enough changing information to make names unique. Seconds may be sufficient for occasional manual captures, but rapid automated captures can occur within the same second. In that case, include a supported counter, incrementing value, higher-resolution time component, or another unique parser value offered by ShareX.

Check the destination folder for an older file with the same name before each test. Moving or deleting test output can make duplicate behavior easier to observe. Success means repeated captures create distinct, predictable names without overwriting earlier files.

3.3 Do not judge the result by a manual rename

Renaming a file later in File Explorer does not change the ShareX filename pattern. It also does not prove what name ShareX originally generated. Likewise, renaming an uploaded file on a remote service does not necessarily rename the local capture.

Always generate a fresh capture after changing the pattern. Then inspect the newest task-history entry and open its actual local folder. This prevents an old file, a copied file, or a manually renamed file from being mistaken for current ShareX output.

3.4 Limit unrelated troubleshooting

Display scaling, microphone selection, audio devices, and network availability usually do not determine the local base filename. They matter only when the relevant workflow depends on them, such as an upload action that applies remote naming or a recording profile that selects a separate output process.

Permissions and destination availability can matter when a variable creates a subfolder or when ShareX cannot use the intended directory. However, if the file saves successfully in the correct location and only its base name is wrong, focus on patterns and task overrides rather than reinstalling drivers or changing Windows security settings.

4. Run a Clean Temporary Test With Minimal ShareX Settings

A controlled test separates parser problems from complicated automation. You do not need to erase your configuration or reinstall ShareX.

1. Record the current pattern so you can restore it.
2. Select a normal local folder that you can write to.
3. Set the filename pattern to ShareXTest.
4. Disable unnecessary upload or post-processing actions for the test if they obscure the local result.
5. Take one screenshot from the main ShareX menu.
6. Confirm the actual saved path in task history.
7. Add one supported date variable through ShareX's naming interface.
8. Repeat the capture and inspect the newest output.
9. Add the remaining variables one at a time.
10. Finally, test the original hotkey or recording workflow.

If the minimal pattern works until one specific variable is added, that variable or the value it inserts is the cause. If the main-menu capture works but the hotkey does not, the hotkey profile is overriding the setting. If neither test uses the new pattern, confirm that you edited the active file-naming field rather than a naming option for uploads, shortened URLs, or another task.

Stop changing settings as soon as the minimal pattern produces the correct local name and the target workflow repeats that result. Additional changes make it harder to identify which fix worked.

5. Check Task History, Logs, and Recent Workflow Output

5.1 Verify the actual saved path in task history

ShareX task history is more reliable than searching a large screenshots folder by eye. Select the newest capture and inspect or open its local file location. Confirm the complete path, including every folder, the base filename, and the extension.

This check reveals whether a separator in the pattern created a directory, whether you inspected an older file, and whether screenshots and recordings are being written to different destinations. It also helps distinguish the local filename from an uploaded URL or remote service name.

5.2 Use logs when the parser or workflow reports an error

If ShareX displays an error, preserve its exact wording. Look for references to invalid characters, malformed paths, missing directories, access denial, or an existing file. The first relevant error is usually more useful than later failures caused by an upload or post-capture action.

When reporting the issue, include a sanitized copy of the pattern, the actual filename produced, the intended filename, the capture method, and whether the problem affects screenshots, recordings, or both. Do not publish private folder names, window titles, API keys, or upload credentials.

6. Quick Fix Checklist

• Confirm the capture saves and that only its name or path is wrong.
• Replace the pattern temporarily with ShareXTest.
• Insert variables from ShareX's own naming controls instead of guessing syntax.
• Use separate, correct tokens for month and minute values.
• Use hyphens or underscores instead of colons in time-based names.
• Keep folder paths in destination settings and names in filename settings.
• Remove Windows-invalid characters and uncontrolled title or OCR text.
• Add a counter or sufficiently precise time value to prevent duplicates.
• Check whether the active hotkey has custom task settings.
• Test screenshots and recordings separately.
• Inspect the newest file's complete path through task history.
• Judge changes only from a fresh capture, not a manually renamed file.

7. Frequently Asked Questions

7.1 Why does ShareX show a variable literally in the filename?

The token is probably unsupported, misspelled, or entered in a field that does not parse it. Insert the variable using ShareX's available naming menu and test it by itself. If it is still literal, remove it and use a supported alternative.

7.2 Why does my ShareX filename contain the wrong month or minute?

Month and minute require different tokens. Reinsert both through ShareX's pattern controls rather than guessing their abbreviations. Use a test performed at a time when the month and minute values are visibly different, which makes a swap easy to detect.

7.3 Why are numbers added to my filenames?

The proposed filename probably already exists. ShareX's duplicate handling may add a suffix or incrementing value to preserve the earlier file. Add a supported counter or more precise changing value if you want uniqueness to be part of the visible pattern.

7.4 Why does the pattern work for screenshots but not recordings?

The recording may use a different task profile, output setting, or workflow. Compare the screenshot and recording entries in task history, then inspect recording-specific settings and the hotkey configuration used to start the recording.

7.5 Can I put a folder name inside the filename pattern?

A slash or backslash is normally interpreted as a path separator, not a decorative filename character. Use ShareX's destination-folder settings for directories. Only use dynamic subfolders when you intentionally want them and have verified that all generated folder values are valid.

7.6 Should I reinstall ShareX if filename patterns are not working?

Usually not. A simple pattern test, task-override check, and inspection of the actual saved path are more targeted. Consider broader repair steps only if settings fail to persist, the application reports damaged configuration, or multiple unrelated ShareX features are also malfunctioning.

A successful ShareX filename pattern produces a legal, predictable, and sufficiently unique local name every time the intended workflow runs. Once a fresh screenshot or recording shows the correct variables in the correct folder, stop adjusting the configuration and restore only the automation steps you actually need.