ShareX Custom Uploader Guide: Self-Hosted Screenshot Links
ShareX is a free and open source screenshot tool for Windows that combines screen capture, screen recording, file sharing and productivity tools.
ShareX's custom uploader documentation, read in October 2026, describes a system that lets you upload images, text, and files to hosting services or shorten and share URLs. This guide follows that documentation: how the custom uploader works, how to set one up cleanly, and how to keep your credentials safe while you do it.
Read ShareX's custom uploader documentation.
Key distinction up front: The custom uploader is for talking to your own or a third-party HTTP endpoint. ShareX also provides guides for Amazon S3, Google Cloud Storage, and Cloudflare R2, so look for a guide to your storage before you write an HTTP request by hand.
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 these ways to extract it:
- JSON using JsonPath syntax, e.g.
{json:data.link}to readdata.linkfrom 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.
If the upload succeeds but the URL ShareX copies is empty or malformed, the parser may be pointing at the wrong field. Look at the raw response your server returns and trace the exact path to the URL string.
Step-by-step: a clean setup
- 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.
- Back up your current ShareX settings first. Export your existing destination configuration so you can roll back if a change misbehaves.
- Create the custom uploader in ShareX (Destinations → Custom uploader settings). Set the request method, destination URL, headers, and body type to match your endpoint.
- Configure the response parser using the right JsonPath, XPath, regex, or header rule so ShareX returns the correct URL.
- Test with a harmless capture — a throwaway image — and confirm the returned link actually opens the file.
- Verify delete/retention behavior if your endpoint supports deletion, so you know how to remove an upload later.
- 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
.sxcuyou 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, follow ShareX's guide for that provider rather than building a generic HTTP request by hand. ShareX's Amazon S3 guide, for example, covers the bucket, the access keys, and an optional custom domain. Keep the generic HTTP custom uploader for endpoints that have no guide.
Maxisnap Studio can also upload to your own server
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. 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.
Maxisnap is not affiliated with ShareX. This page describes ShareX as its official site presented it in October 2026; check the official site for its current features, pricing and platforms. getsharex.com