ShareX Custom Uploader Returns 404 Not Found: How to Fix It

A ShareX custom uploader returning 404 Not Found usually means the upload request reached a web server, but the server could not match the requested URL to a valid upload route. The most common causes are an incorrect base URL or endpoint path, the wrong HTTP method, a changed API route, an environment-specific domain, or confusion between the upload endpoint and the public file URL. This guide focuses on those route-related problems rather than authentication failures or JSON response parsing.

Work through the checks in order and test after every change. As soon as the server accepts the upload and ShareX receives a successful response, stop changing settings. Making several speculative changes at once can hide the original cause.

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

Begin by confirming that the failure is actually an HTTP 404 response. A 404 indicates that ShareX contacted a server and requested a resource the server did not recognize. This is different from a connection timeout, DNS failure, certificate warning, 401 Unauthorized response, or 403 Forbidden response.

1.1 Perform a Small Upload

Create a tiny test image and upload it through the custom uploader. A small file reduces waiting time and separates route troubleshooting from capture or recording problems.

1. Capture a small region of the screen.
2. Open the ShareX custom uploader settings you intend to test.
3. Use the uploader's test function if available, or upload the captured image through the configured destination.
4. Record the exact status code, requested address, and response body.

If the result is consistently 404 Not Found, the problem is probably reproducible and tied to the request route. If one upload succeeds and another fails, compare their destinations, file types, workflow actions, and uploader selections before editing the endpoint.

1.2 Identify Which Server Returned the 404

Look at the requested host and any server-generated error page or response text. A branded hosting-provider page, reverse-proxy message, application error page, or plain JSON error can reveal which layer rejected the route.

For example, if you intended to send the request to an API domain but the error came from your public website, ShareX is probably using the wrong base domain. If the correct API server responded but reported that the route was not found, concentrate on the path and HTTP method.

Success at this stage means you can reproduce the same 404 with a known uploader and identify the host receiving the request. Once confirmed, do not alter screenshot, OCR, recording, or editor settings because they do not control the server route.

2. Check the ShareX Settings Directly Related to This Problem

The most important fields are the request URL, HTTP method, request body configuration, and final URL template. The request URL tells ShareX where to upload. The final URL template tells ShareX what address to copy or open after a successful upload. They serve different purposes.

2.1 Verify the Base URL and Endpoint Path

Compare the request URL in ShareX with the uploader service's current documentation or known working configuration. Examine the entire address, not only the domain.

• Confirm the scheme is correct, such as HTTPS rather than HTTP.
• Confirm the hostname is exact, including any API subdomain.
• Confirm the full route is present, such as /api/upload.
• Check route versions such as /v1/ or /v2/.
• Remove duplicated path segments introduced when joining a base URL and endpoint.
• Look for spelling errors, missing hyphens, and incorrect singular or plural words.

Suppose the correct endpoint is https://api.example.com/v1/upload. Requests to https://example.com/v1/upload, https://api.example.com/upload, or https://api.example.com/v1/uploads may all return 404 even though the service itself is online.

After correcting the address, run one small upload. Success means the service returns its expected success status and response instead of a route-not-found message. Stop modifying the request URL if that happens.

2.2 Check for an HTTP Method Mismatch

Web applications can route requests by both path and method. An endpoint may accept POST /api/upload but have no route for GET /api/upload or PUT /api/upload. Depending on the server framework, the wrong method may produce 404 Not Found or 405 Method Not Allowed.

Set ShareX to the method required by the uploader, usually POST for a file upload, but do not assume. Use the service documentation, server route definition, or a previously working configuration as the authority.

Success means the request reaches the upload handler rather than a generic missing-route page. If the status changes from 404 to a validation error, file-field error, or authentication error, the route is probably now correct. Stop changing the route and address the new error separately.

2.3 Separate the Upload URL From the Public File URL

The upload URL is the endpoint that receives the file. The public file URL is the address used to view the uploaded file afterward. Putting the public URL in the request URL field is a common cause of 404 responses.

For example, ShareX might need to send the file to https://api.example.com/upload, while a successful response supplies an identifier used to create https://cdn.example.com/files/abc123.png. The CDN address is not necessarily capable of accepting uploads.

Keep the API endpoint in the request URL field. Use the service's response data or documented URL pattern only in the result or URL template. Do not troubleshoot the result template until the server accepts the request. A bad result template usually affects the copied link after an upload, while a bad upload endpoint prevents the upload itself.

2.4 Test Trailing Slash Variations Carefully

Some servers treat /upload and /upload/ as the same route. Others redirect one to the other, and some recognize only one form. Redirects can also behave differently for POST requests, depending on the server and redirect status.

Match the documented endpoint exactly. If documentation is unclear, test one controlled variation at a time:

1. Test the endpoint exactly as currently configured.
2. Add or remove only the final slash.
3. Repeat the same small upload.
4. Keep the version that reaches the upload handler.

Do not randomly add slashes between path components. A doubled slash such as /api//upload can be interpreted differently by proxies and applications.

2.5 Confirm the Environment-Specific Domain

Development, staging, and production environments commonly use different domains and route prefixes. A configuration exported from another computer may still point to a local, test, or retired environment.

• localhost refers to the Windows computer running ShareX, not a remote server.
• A staging domain may expose different API routes from production.
• A company VPN may be required to reach an internal development host.
• A regional or tenant-specific hostname may be part of the correct endpoint.
• An old custom domain may now direct to a generic website instead of the API.

Verify both the domain and route belong to the same intended environment. Success means the request arrives at the environment where the upload route is actually deployed.

3. Check Windows, Network, Destination, and Workflow Factors

Most Windows capture and display settings cannot create an HTTP 404. The screenshot hotkey, monitor scaling, microphone, encoder, OCR language, and image editor may affect content creation, but they do not determine whether a web server recognizes an upload route. Focus only on workflow factors that can select or rewrite the destination.

3.1 Confirm the Active Destination

ShareX can use different destinations for images, text, files, and URL shortening. A task workflow can also override a default destination. Confirm that the failed upload is using the custom uploader you edited.

1. Check the configured image or file uploader for the relevant task.
2. Review any hotkey-specific task settings.
3. Check whether a workflow overrides the global destination.
4. Run the test directly against the intended custom uploader.

If direct testing succeeds but a normal screenshot still returns 404, the endpoint is probably valid and the workflow is selecting another uploader or older configuration.

3.2 Consider Proxies, Redirects, and Rewritten Domains

A proxy, VPN, security gateway, or company reverse proxy can direct a request to a different server. However, do not blame the network merely because the response is 404. First inspect the final host and response branding.

If a browser, command-line test, or server log shows that the request is redirected to a login page, generic website, or different hostname, investigate the redirect or proxy rule. The goal is for the POST request to reach the exact upload host and route without being transformed into a request for an unrelated page.

3.3 Rule Out File-Type Route Differences

Some services use separate endpoints for images, videos, and general files. A screenshot workflow may use an image endpoint while a screen recording is sent as a file or video. If only one content type returns 404, compare the destination and endpoint selected for each type.

Success means all relevant workflows point to routes that the server actually exposes. Do not force every content type through one endpoint unless the service documents that behavior.

4. Run a Clean Temporary Test With Minimal ShareX Settings

A minimal test helps separate the endpoint from hotkeys, after-capture actions, clipboard actions, and task overrides. It should not replace your main configuration until it works.

4.1 Build the Smallest Useful Test

1. Duplicate or export your existing uploader configuration as a backup.
2. Create a temporary custom uploader.
3. Enter only the documented request URL.
4. Select the documented HTTP method.
5. Add the required file form field and only the essential request fields.
6. Leave optional result URL formatting and automation actions out initially.
7. Upload a small image directly.

This test is deliberately narrow. It does not attempt to fix authentication or response parsing. Its purpose is to determine whether ShareX can reach the correct route using the correct method.

If the temporary uploader stops returning 404, compare it with the original configuration one field at a time. The difference may be an old endpoint, duplicated path, wrong method, or workflow override. If the clean test still returns 404, verify the route independently or ask the server administrator whether that route is deployed.

4.2 Test the Endpoint Outside ShareX Conceptually

An independent request can determine whether the failure belongs to ShareX or the server configuration. Use a trusted API client, a documented command-line example, or the service's own testing console. Send the same method to the same URL with a small test file.

A browser address-bar test is usually insufficient because it sends a GET request, while an upload endpoint often requires POST. Seeing 404 in a browser does not prove that the POST route is missing. Conversely, seeing a normal website page at the domain root does not prove that the upload path exists.

If an equivalent request outside ShareX also returns 404, changing capture settings in ShareX will not help. The URL, method, deployment, or server route must be corrected. If the independent request works, compare its exact URL and method with the ShareX configuration.

5. Check Task History, Logs, and Raw Responses

ShareX task history and debugging information can help confirm what happened after a test. Look for the requested address, HTTP status, response headers, response body, selected destination, and any redirect target.

5.1 Read the Raw Response Safely

Before sharing a raw response publicly, remove API keys, authorization headers, cookies, signed URLs, internal hostnames, personal file names, and other sensitive information. Even though this guide does not focus on authentication, logs can still contain credentials.

The raw response may reveal useful route clues:

• A generic hosting page suggests the request reached the wrong site or virtual host.
• A JSON message such as route not found suggests the API application received the request but did not match it.
• An HTML framework page may identify an application-level missing route.
• A redirect response may show that the upload request was sent elsewhere.
• A different status after an edit may confirm that the route problem is resolved.

Do not treat every non-success response as the same problem. If the response changes from 404 to 400, 401, 403, 405, 413, or 422, the route correction may have worked. Stop changing the endpoint and troubleshoot the new status according to its meaning.

5.2 Determine Whether the API Route Changed

If the uploader worked previously and suddenly began returning 404, check for a service migration, API version retirement, domain change, or route redesign. Compare your configuration with current official documentation rather than an old forum post or exported configuration.

Self-hosted users should also verify that the upload route is deployed in the active application and exposed through the reverse proxy. An application update can change a route prefix, while a proxy configuration can omit the new path.

Success means the request reaches a currently supported route and produces the service's expected upload response. Once that occurs, preserve the working configuration before restoring optional actions.

6. Quick Fix Checklist

• Reproduce the 404 with a small test image.
• Confirm which hostname returned the error.
• Match the base URL and full endpoint path to current documentation.
• Verify the API version and route spelling.
• Use the required HTTP method, commonly POST for uploads.
• Keep the upload endpoint separate from the public file URL.
• Match the documented trailing-slash format.
• Remove duplicated slashes and repeated path segments.
• Confirm the domain belongs to the correct development, staging, or production environment.
• Verify the active ShareX workflow uses the uploader you edited.
• Test the same method and endpoint outside ShareX when possible.
• Inspect task history and raw responses after removing sensitive data.
• Stop editing the endpoint when the response changes from route not found to a different, specific error.

7. Frequently Asked Questions

7.1 Why does the endpoint open in my browser but fail in ShareX?

A browser normally sends a GET request when you enter an address. ShareX may send POST, PUT, or another method. Servers can define different routes for each method, so a page loading in a browser does not prove that the upload method is accepted. Compare ShareX with a documented request using the same method.

7.2 Can a wrong HTTP method really produce 404 instead of 405?

Yes. Although 405 Method Not Allowed is designed for cases where a resource does not support a particular method, some frameworks, proxies, and server configurations return 404 when no route matches both the path and method. Verify the method whenever the URL appears correct.

7.3 Is the copied file link the same as the upload endpoint?

Usually not. The upload endpoint receives the file, while the copied link points to the uploaded resource on a website, file domain, or CDN. Entering a public file URL pattern as the request endpoint can cause an immediate 404.

7.4 Should I change authentication fields when I see 404?

Not first. A straightforward 404 generally points to a path, host, method, or deployment mismatch. Some systems intentionally hide protected routes, but you should first confirm the exact documented endpoint and method. Authentication failures are more commonly reported as 401 or 403 and are outside this route-focused fix.

7.5 Why did ShareX stop working when I did not change its settings?

The server side may have changed. The provider could have moved the API to another domain, introduced a new version, retired an old route, or modified its reverse-proxy configuration. Compare the saved uploader against current official documentation and recent server deployment information.

7.6 When should I stop changing ShareX settings?

Stop changing the endpoint as soon as ShareX reaches the upload handler. Evidence includes a successful upload, a valid service response, or a new specific error such as a missing file field or unauthorized request. A new error may require another fix, but it shows that the original 404 route problem has probably been resolved.