ShareX Custom Uploader Guide: Self-Hosted Screenshot Links

One of the reasons power users love ShareX is that it doesn't lock your screenshots into someone else's cloud. With a custom uploader, ShareX can push every capture to a destination you control — your own server, an object-storage bucket, or a link-shortening endpoint — and hand you back a shareable URL automatically. This guide explains how the custom uploader system works, how to set one up cleanly, and how to keep your credentials safe while you do it.

What a custom uploader actually is

As ShareX's own documentation puts it, the custom uploader feature is mainly used by people who host their own services. In practice it's a small definition that tells ShareX: when I capture something, send it to this URL, using this request, and find the resulting link in this part of the response. Get those three things right and ShareX quietly uploads and copies a working URL every time you snip.

The request: methods and body types

ShareX's custom uploader supports the standard HTTP methods — GET, POST, PUT, PATCH, and DELETE. As a rule of thumb from the docs: if the request only carries parameters and no body, GET is preferred; if it sends a file as multipart/form-data, POST is the usual choice.

For the request body, ShareX offers several types so it can match whatever your endpoint expects:

• No body — parameters only.
• Form data (multipart/form-data) — the typical choice for uploading a file.
• Form URL encoded (application/x-www-form-urlencoded).
• JSON (application/json).
• XML (application/xml).
• Binary — the raw file as the body.

Your server's API documentation tells you which method and body type it expects; you're simply mirroring that in the ShareX definition.

Parsing the response: where's the link?

After the upload, your endpoint responds — usually with JSON, XML, or plain text — and you need to tell ShareX which field holds the final URL. ShareX gives you four ways to extract it:

• JSON using JsonPath syntax, e.g. {json:data.link} to read data.link from a JSON response.
• XML using XPath, e.g. {xml:/files/file[1]/url}.
• Regex for pattern-matching a plain-text response.
• Headers to read a URL returned in a response header.

This is the step people most often get wrong: the upload succeeds, but the "URL" ShareX copies is empty or malformed because the parser points at the wrong field. When that happens, look at the raw response your server returns and trace the exact path to the URL string.

Step-by-step: a clean setup

1. Read your endpoint's API docs and note the method, the body type, the field name for the file, any auth header, and the exact location of the URL in the response.
2. Back up your current ShareX settings first. Export your existing destination configuration so you can roll back if a change misbehaves.
3. Create the custom uploader in ShareX (Destinations → Custom uploader settings). Set the request method, destination URL, headers, and body type to match your endpoint.
4. Configure the response parser using the right JsonPath, XPath, regex, or header rule so ShareX returns the correct URL.
5. Test with a harmless capture — a throwaway image — and confirm the returned link actually opens the file.
6. Verify delete/retention behavior if your endpoint supports deletion, so you know how to remove an upload later.
7. Set it as your active destination only once a real test link works end to end.

Sharing and reusing configs: .sxcu files

A finished custom uploader can be exported as a .sxcu file. Another user can import it by double-clicking the file, and ShareX applies the destination configuration automatically. That makes it easy to share a working setup across your own machines or with a team — but it's also exactly where secrets leak, so read the next section before you send one to anyone.

Protect your secrets

A custom uploader often contains API keys, tokens, or signed credentials. Treat a .sxcu file like a password:

• Before sharing a config, strip or replace real credentials with placeholders. A .sxcu you post publicly can expose a live key.
• Prefer scoped, revocable tokens over long-lived master keys, so a leak is contained and easy to rotate.
• Always upload over HTTPS so credentials and files aren't sent in the clear.
• Rotate anything that may have been exposed — screenshots and their configs travel further than you expect.

Prefer a built-in destination when there is one

If your storage is Amazon S3, Google Cloud Storage, or Cloudflare R2, use ShareX's dedicated built-in guide for that provider rather than building a generic HTTP request by hand. The built-in destinations handle the provider-specific signing and custom-domain setup for you, which is fewer moving parts and fewer places to make a mistake. Reserve the generic HTTP custom uploader for endpoints that don't have a built-in option.

If you'd rather not hand-configure requests

The custom uploader is powerful precisely because it's fully configurable — that flexibility is the point, and for self-hosters it's ideal. If you like owning your storage but would rather point-and-pick a backend than author HTTP requests and response parsers, a more guided setup can save time. Maxisnap Studio, a one-time upgrade, adds custom upload backends — SFTP, FTP, S3-compatible, and HTTP — so your Windows captures upload to storage you control with a simpler configuration flow. It's a different trade-off from ShareX's fully open request builder, aimed at people who want ownership without the request-level detail. You can see how Maxisnap's upload options are structured on the SFTP upload and S3 / R2 upload pages, or read the broader Maxisnap and ShareX overview.

ShareX is a trademark of its respective owner; Amazon S3, Google Cloud Storage, and Cloudflare R2 are trademarks of their respective owners. ShareX feature details were checked against ShareX's official documentation on August 17, 2026 and may change. Maxisnap is an independent product and is not affiliated with, endorsed by, or sponsored by any of these projects or companies.