ShareX Custom Uploader Response Not Parsed: How to Fix JSON and URL Fields

Your ShareX custom uploader can send a file successfully and still fail to produce a usable URL. The server may return a valid response, yet ShareX leaves the URL empty, copies the wrong value, misses the deletion link, or reports an unhelpful parsing error. This usually points to a mismatch between the actual response body and the response fields configured in ShareX. It is different from failed authentication, a rejected request, or an upload that never reached the server.

The fastest way to solve a ShareX custom uploader response not parsed problem is to capture the raw response, identify its exact format, and configure each response field to match that format. Work through the steps below in order. Once a small test upload returns the correct final URL, stop changing unrelated capture, recording, or application settings.

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

Begin by separating a successful upload with bad parsing from an actual upload failure. These cases can look similar in ShareX, but they require different fixes.

1.1 Successful Upload Versus Failed Request

You probably have a parsing problem when the remote service receives the file and the response body contains the expected information, but ShareX does not extract it. Common signs include:

• The uploaded file appears on the server or in the service dashboard.
• The server returns a success status and a response body.
• The response visibly contains a URL, file identifier, or deletion token.
• ShareX shows an empty result, an incorrect URL, or a parsing-related error.
• The upload completes, but nothing useful is copied to the clipboard.

You probably have an upload, authentication, or network problem when the server rejects the request before returning a successful upload result. Look for an HTTP 401 or 403 authentication response, an HTTP 400 validation response, an HTTP 413 file-size response, a timeout, a DNS error, or a connection failure. Fixing a JSON path will not repair an invalid API key or a rejected multipart request.

Success at this stage means you can state which of these two situations applies. If the server did not accept the upload, pause response-field troubleshooting and fix the request itself first.

1.2 Use a Small, Predictable File

Choose a small image or text file that the destination definitely accepts. Avoid testing first with a long screen recording, a large video, or a file type subject to special validation. Run the custom uploader test from ShareX's custom uploader configuration if available, or upload the small file through the normal destination workflow.

A predictable test reduces unrelated variables. If a small PNG is accepted and produces a response, you can concentrate on parsing. If only certain file types fail, inspect the endpoint's file restrictions, form field name, and workflow rather than assuming every result is a JSON problem.

1.3 Capture the Raw Response Body

The raw response body is the most important evidence. Do not configure fields from an API documentation example unless the live response is identical. Servers sometimes return different structures for success, validation errors, expired credentials, or rate limits.

For example, a successful response could be:

{"url":"https://files.example.test/a1.png","delete_url":"https://files.example.test/delete/x9"}

Another service might return:

{"data":{"links":{"view":"https://files.example.test/a1.png","delete":"https://files.example.test/delete/x9"}}}

Those responses contain similar information but require different field expressions. Save the exact response, including braces, brackets, quotation marks, escaping, and capitalization. Success means you can see the returned URL in the raw body and know where it sits in the response structure.

2. Check the ShareX Settings Directly Related to This Problem

Open the custom uploader configuration used by the failing destination. Confirm that you are editing the same uploader selected by the active after-upload workflow. A perfectly configured test uploader will not help if the real task is still routed to another destination.

2.1 Match the URL Field to the Actual JSON Path

The URL response field must point to the value that ShareX should use as the upload result. A top-level property is straightforward: if the response is {"url":"https://files.example.test/a1.png"}, configure the URL field to read the url property using the response-expression syntax supported by the custom uploader editor.

Property names are not interchangeable. A response containing fileUrl does not have a property named url. Also check capitalization if the endpoint distinguishes names such as URL, Url, and url.

After correcting the field, run one test. Success means ShareX displays or records the exact returned file URL. If it does, stop modifying the URL expression.

2.2 Follow Nested Response Objects

Many APIs wrap upload details inside objects such as data, result, file, or links. Configuring only the final property name may not be enough when the desired value is nested.

For this response:

{"data":{"file":{"url":"https://files.example.test/a1.png"}}}

The response expression must traverse data, then file, then url. Use ShareX's custom uploader tester or response preview to confirm that the expression resolves to a string rather than the complete object.

If the preview returns something resembling {"url":...}, you selected an object, not the URL value inside it. Continue one level deeper. Success means the resolved result is only the usable URL string.

2.3 Select an Item From an Array

Some upload APIs return a list even when you upload one file:

{"files":[{"url":"https://files.example.test/a1.png","thumbnail":"https://files.example.test/thumbs/a1.png"}]}

In this case, the path must select the first item in files before selecting url or thumbnail. If the expression targets files.url without selecting an array element, parsing may fail or return no value.

Confirm whether array indexing is zero-based in the expression format shown by the ShareX editor and documentation. The first element is commonly selected with index zero. Success means the first uploaded item's link appears as a normal string, not as an array or blank result.

2.4 Configure Optional Fields Independently

The main URL, thumbnail URL, deletion URL, and error message are separate outputs. Do not assume that fixing one automatically fixes the others. Map each field to its actual response location:

• URL: The public page or direct file link ShareX should treat as the final result.
• Thumbnail URL: A preview image returned by the service, if one exists.
• Deletion URL: A complete deletion link, not merely a deletion token unless you build a URL from it.
• Error message: The human-readable message returned when the request fails.

If an optional field does not exist in the response, leave it empty rather than pointing it to an unrelated property. Success means the fields that the server actually returns are populated correctly, while unavailable optional fields remain harmlessly blank.

2.5 Distinguish Plain Text From JSON

Not every upload endpoint returns JSON. A service might return only:

https://files.example.test/a1.png

That is plain text, so a JSON property such as url cannot be extracted from it. Configure the response handling to use the response body itself, according to the options available in the custom uploader editor.

The reverse also matters. If the body is a JSON object, treating the entire body as the final URL can copy braces and property names instead of a link. Inspect the first non-whitespace character: an opening brace usually indicates a JSON object, while an opening bracket usually indicates a JSON array. A bare URL is plain text.

2.6 Do Not Rely Only on the Content Type

A correct server commonly labels JSON as application/json, but some endpoints return valid JSON with text/plain. Others claim to return JSON but send an HTML error page from a proxy or login system.

Use both the response headers and the actual body. If the body starts with HTML, contains a sign-in page, or shows a gateway error, changing a JSON path is not the right fix. If the body is valid JSON despite an imperfect content type, configure the parser from the body you actually receive and consider correcting the server header if you control the endpoint.

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

Windows display scaling, microphone selection, OCR language, and screen-capture region settings do not normally affect response parsing. Focus on factors that can change the request, response, or final workflow output.

3.1 Verify the Active Destination

ShareX can use different destinations for images, text, files, and URL shortening. Confirm that the uploaded content type is routed to the custom uploader you edited. Also check whether a hotkey uses task-specific settings that override the general destination.

A useful test is to invoke the destination directly rather than through a complicated hotkey chain. Success means the task history identifies the intended custom uploader and shows the same endpoint you configured.

3.2 Check Authentication Without Confusing It With Parsing

An expired token can cause an endpoint to return JSON, but that does not make the problem a success-response parsing issue. For example:

{"error":{"message":"Invalid API token"}}

The JSON may be perfectly valid while no upload occurred. Check the HTTP status, verify required headers, and confirm that the file exists remotely. If the response is an authentication error, repair the token or authorization header first.

3.3 Inspect Proxies, Security Tools, and Redirects

A corporate proxy, web filter, VPN, or authentication gateway can replace the expected API response with HTML or redirect the request to a login page. Security software may also block a destination while allowing ShareX itself to run.

Compare the endpoint and response with the same network conditions used by ShareX. If a redirect changes the host or produces an HTML page, resolve that network behavior before editing response fields. Success means ShareX receives the API's expected success body directly.

3.4 Check URL Escaping and Returned Slash Characters

JSON often displays slashes as https:\/\/files.example.test\/a1.png. In valid JSON, a proper JSON parser should decode those escaped slashes into a normal URL. Do not manually add or remove backslashes unless testing proves the server is returning malformed or double-encoded data.

Double encoding is different. A property might contain a JSON document as a quoted string rather than a normal nested object. It may look like:

{"data":"{\"url\":\"https:\/\/files.example.test\/a1.png\"}"}

Here, data is a string containing encoded JSON. A normal nested path cannot automatically treat that string as an object in every configuration. The cleanest fix, when you control the server, is to return a real nested object. Success means ShareX resolves a normal absolute URL beginning with http:// or https://.

4. Run a Clean Temporary Test With Minimal ShareX Settings

A minimal test helps determine whether the response expression is wrong or a larger workflow is hiding the correct result.

4.1 Create a Temporary Uploader Configuration

1. Duplicate the existing custom uploader so the working portions are preserved.
2. Keep only the required endpoint, request method, file form field, and authentication values.
3. Configure only the main URL response field at first.
4. Upload one small, accepted file.
5. Compare the raw response with the resolved URL.

Do not add thumbnail, deletion, or error expressions until the main URL works. This prevents one optional field from distracting you from the core result.

4.2 Test With a Known Simple Response

If you control the server or can use a safe development endpoint, temporarily return a minimal response such as:

{"url":"https://example.test/test.png"}

Then point the URL field at url. If ShareX extracts that value, its basic JSON handling works and the original response structure is the likely cause. Gradually reintroduce nesting, arrays, and optional fields until you identify the mismatch.

If you do not control the server, do not send private screenshots or API credentials to a public response-testing service. Instead, use the custom uploader's built-in test and inspect the real endpoint's output.

4.3 Restore Workflow Actions One at a Time

After parsing succeeds, restore after-upload actions individually. Relevant actions can include shortening the URL, opening it, showing a notification, or copying it to the clipboard. A URL shortener failure after a successful custom upload can make the overall workflow appear broken even though the original response was parsed correctly.

Success means the task history first contains the correct uploaded URL and each restored action behaves as expected. Stop changing parser settings once that condition is met.

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

ShareX troubleshooting is easier when you inspect the most recent task instead of repeatedly changing fields by guesswork.

5.1 Review the Task Result

Open the relevant task in ShareX history and compare its result with the raw server response. Determine whether the result is blank, an entire JSON object, a partial path, or a valid URL that was later altered.

• A blank result usually suggests an unmatched path or missing property.
• An entire JSON object suggests the whole body was selected instead of one property.
• A fragment may indicate an incorrect nested path or URL template.
• A correct initial URL followed by failure suggests a later workflow action.

5.2 Read the Error Literally

A parsing error, an HTTP error, and a clipboard error identify different stages. Save the exact message rather than paraphrasing it. Also note the status code and whether the server response is a success object or an error object.

APIs often use separate formats for success and failure:

{"data":{"url":"https://files.example.test/a1.png"}}

{"error":{"message":"Unsupported file type"}}

Configure the main URL from the success structure and the error-message field from the error structure. Do not point the URL field at an error property simply because both responses are JSON.

5.3 Confirm Clipboard Behavior After Parsing

A successful parse does not guarantee clipboard output if the appropriate after-upload action is disabled. Once the history shows the correct final URL, enable the action that copies the URL to the clipboard. Then upload another small test file and paste into Notepad.

If Notepad receives the expected URL, parsing and clipboard delivery are both working. If history contains the correct URL but the clipboard does not, leave the response expression alone and troubleshoot the after-upload action or another application that may be replacing clipboard contents.

6. Quick Fix Checklist

1. Confirm the file was actually accepted by the remote service.
2. Record the HTTP status and exact raw response body.
3. Identify whether the body is JSON, plain text, HTML, or double-encoded JSON.
4. Verify that the active task uses the custom uploader you edited.
5. Match the URL field to the exact property name and capitalization.
6. Traverse all nested objects in the correct order.
7. Select the first array item before reading its URL property.
8. Map thumbnail and deletion URLs independently.
9. Map error messages from the endpoint's separate error format.
10. Do not manually alter normal JSON slash escaping.
11. Test with one small file and only the main URL field enabled.
12. Check task history before restoring optional workflow actions.
13. Enable copying the final URL to the clipboard after parsing works.
14. Stop changing settings when history and Notepad show the correct URL.

7. Frequently Asked Questions

7.1 Why Does the Upload Succeed but ShareX Show No URL?

The usual cause is that the configured URL response field does not match the live response. The URL may be nested under another object, stored in the first item of an array, named differently, or returned as plain text. Inspect the raw body and map the field to the exact value.

7.2 How Do I Know Whether This Is Parsing or Authentication?

Check the HTTP status, raw response, and remote service. If the file exists remotely and the success response contains its URL, parsing is the likely issue. If the server returns an invalid-token message or the file never appears, fix authentication or request construction first.

7.3 What If the API Returns an Array?

Select the relevant array item before selecting its URL property. For a one-file upload where the response contains files, this is usually the first item. Confirm the indexing syntax through ShareX's custom uploader editor or official documentation.

7.4 Should I Remove Backslashes From an Escaped JSON URL?

Usually not. Escaped slashes are valid inside JSON strings and should decode into a normal URL. Manual replacement can corrupt a valid response. Investigate only if the extracted result still contains literal backslashes or the server returns double-encoded content.

7.5 Why Is the Correct URL in History but Not on the Clipboard?

That indicates parsing is working. Enable the after-upload action that copies the URL, test again, and paste into Notepad. Also check whether a later action or clipboard utility is replacing the value. Do not keep changing the JSON path when history already shows the correct result.

7.6 When Should I Stop Troubleshooting the Parser?

Stop changing parsing settings when a small upload is accepted, task history contains the expected absolute URL, and any configured thumbnail or deletion links resolve correctly. If a later action still fails, troubleshoot that specific workflow stage instead of revisiting the response fields.