0x0.st Alternative: curl Uploads That Don't Hang Around for a Year

If you want a curl one-liner that behaves like 0x0.st but forgets the file in days rather than months, swap the URL:

# sto.care: 100 MB cap, link dies in 72 hours
$ curl -T debug.log https://ul.sto.care
{"url":"https://dl.sto.care/mjrxiq1odb","expiresAt":"2026-10-04T20:19:21.615Z"}

# The 0x0.st form style works against the same endpoint
$ curl -F "[email protected]" https://ul.sto.care

# For comparison, 0x0.st itself: 512 MiB cap, and a file
# this small would be retained for roughly 363 days
$ curl -F "[email protected]" https://0x0.st

Both the -T and the -F form work against ul.sto.care, so migrating an existing 0x0.st script is usually a pure URL swap. 0x0.st is a good service and it has been running for close to a decade. This post is about the one place it does not fit: files you actively want gone.

How 0x0.st retention actually works

The most common misreading of 0x0.st is that bigger files are kept longer. It is the opposite. Retention is inverse to size, so the smallest uploads are kept the longest. Here is the formula, printed on the 0x0.st homepage and read there on 1 October 2026:

min_age  = 30 days
max_age  = 1 year
max_size = 512.0 MiB

retention = min_age + (min_age - max_age) * pow((file_size / max_size - 1), 3)

Run the numbers and the shape of the curve becomes clear. A log file, a stack trace, a config dump: all of these are small, and small means close to a full year on disk.

  file size      retention
  ---------      ---------
      1 MiB      363.0 days
     10 MiB      345.8 days
     50 MiB      276.1 days
    100 MiB      204.6 days
    256 MiB       71.9 days
    512 MiB       30.0 days

That is by design and it is a reasonable design. 0x0.st is a paste and file host, and a paste that evaporates in three days is not much use when you linked it from a bug report two months ago. The operator runs it on roughly 400 GB of disk and 10 to 40 TB of monthly traffic, so holding small files for a year costs very little.

0x0.st also lets you override it. -Fexpires=24 asks for 24 hours, -Fsecret= gives you a longer unguessable URL, and every first upload returns an X-Token header you can use to delete the file later:

# A longer, hard-to-guess URL
$ curl -F "[email protected]" -Fsecret= https://0x0.st

# Ask for a shorter retention, in hours
$ curl -F "[email protected]" -Fexpires=24 https://0x0.st

# Delete it later, using the X-Token from the upload response headers
$ curl -Ftoken=token_here -Fdelete= https://0x0.st/abc.txt

Those are genuinely good features and sto.care does not have an equivalent for either the custom expiry or the delete token. If you need to pick your own retention window per upload, 0x0.st is the better tool and you should use it.

What 0x0.st asks you not to upload

This is the part worth reading before you wire 0x0.st into anything automated. Its terms of service name the categories it is not a platform for, and three of them cover exactly the jobs people reach for a curl uploader to do:

• Backups. Not a backup target, explicitly.
• CI build artifacts. Also explicit.
• Other automated mass uploads. The catch-all.
• Database dumps with personal information are listed alongside doxxing, so a production dump with real user rows is out.

On top of that, Tor exit nodes are blocked at the firewall, and the guidance for client authors asks you to send a user agent that uniquely identifies your program and to never masquerade as a browser, because that gets detected and blocked automatically. If you are searching for why 0x0.st is blocked for you, those rules are the first place to look. The operator also says bans get lifted if you explain what happened.

None of this is 0x0.st being difficult. It is one person in Germany moderating a donation-funded service, and the limits are what keep it alive. But it does mean that if your use case is a script, a CI job or a nightly dump, 0x0.st is asking you to go elsewhere or to self-host.

Why short expiry matters for logs and dumps

A debug bundle is the most over-shared artifact in software. It has hostnames, internal IPs, env var names, sometimes a token that someone forgot to redact. The useful life of that file is the length of one debugging session. The risk window, if the link is public for 363 days, is a year.

72 hours is a deliberate choice: long enough for a colleague in another timezone to pick it up, short enough that you do not have to remember to clean up. sto.care also caps each file at 10 downloads, so a link that leaks into a public issue tracker stops working quickly rather than serving forever. You do not have to trust your future self to revoke anything.

The honest caveat: expiry is not redaction. A short-lived public link is still a public link while it lives. Strip secrets before you upload, the same as you would for any host. 0x0.st makes the same point in its own notes to client authors, and asks that software uploading user logs get consent first and let people review what is being sent. That is good advice regardless of which endpoint you point it at.

JSON and real filenames instead of a bare URL

0x0.st answers an upload with a plain URL and a generated short name. That is fine for pasting into chat and slightly annoying in a script, where you also want to know when the thing expires. The sto.care API returns JSON with both fields, so jq gets you what you need without parsing text:

# Grab just the URL, and the expiry, from the JSON
$ curl -sT debug.log https://ul.sto.care | jq -r '.url, .expiresAt'
https://dl.sto.care/mjrxiq1odb
2026-10-04T20:19:21.615Z

# A shell function for your .bashrc
share() { curl -sT "$1" https://ul.sto.care | jq -r .url; }

The filename survives too. sto.care sets Content-Disposition from the original name, so curl -LO writes debug.log rather than a random id. With 0x0.st you append a filename to the path yourself if you want the download to land under a sensible name:

# sto.care preserves the original filename via Content-Disposition
$ curl -LO https://dl.sto.care/mjrxiq1odb
$ ls
debug.log

# 0x0.st returns a bare URL with a generated short name. You can
# append any filename to the path to make the saved copy sensible:
#   https://0x0.st/aaa.jpg/image.jpeg

The full set of sto.care API limits: 100 MB per file, no auth or signup, 10 uploads per IP per UTC day, links live 72 hours, 10 downloads per file. Our guide to curl file uploads covers the other flags and the CI recipes.

When 0x0.st is the better choice

Clearly and without hedging, pick 0x0.st when:

• Your file is over 100 MB. 0x0.st takes up to 512.0 MiB, which is more than five times the sto.care API cap. This is the main reason to choose it and there is no way around it.
• You want to self-host. 0x0 is open source at git.0x0.st/mia/0x0, and the operator actively encourages people to clone it. Running your own instance is also the right answer if you need to test a client, or if you want an automated uploader without leaning on someone else's donations.
• You need the link to outlive the week. A URL in a long-running bug report wants months, not 72 hours.
• You want per-file control. Custom expiry, secret URLs and delete tokens are all things 0x0.st has and sto.care does not.
• You want a decade of track record. 0x0.st has it.

And if the file is much bigger than either, the sto.care web app handles up to 25 GB with 7-day links, free and without an account. Related reading on the other hosts in this space: what replaced transfer.sh and the file.io comparison.

FAQ

What is a good 0x0.st alternative for curl uploads?

curl -F "[email protected]" https://ul.sto.care uses the same multipart form 0x0.st does, and curl -T works as well. The cap is 100 MB rather than 512 MiB, but links expire in 72 hours, the response is JSON, and the original filename is preserved. No account, no API key.

How long does 0x0.st keep files?

Between 30 days and one year, inverse to size. A 1 MiB file is held about 363 days; a full 512 MiB upload expires after 30. The cubic formula above is the one published on the 0x0.st homepage.

What is the 0x0.st upload size limit?

512.0 MiB, confirmed on the homepage on 1 October 2026. Larger than sto.care's 100 MB API cap, which is the clearest reason to prefer 0x0.st.

Why was my IP blocked from 0x0.st?

Terms of service violations get the originating IP blocked, Tor exit nodes are blocked at the firewall, and a user agent pretending to be a browser is blocked automatically. Backups, CI artifacts and automated mass uploads are all against the rules. Bans can be lifted if you ask and explain.

Can I upload CI build artifacts to 0x0.st?

No. Its terms list backups, CI build artifacts and other automated mass uploads as out of scope. For scripted uploads use an endpoint built for it, such as the sto.care API, or self-host your own 0x0 instance.

Try it

One command, no signup, gone in 72 hours:

$ curl -T debug.log https://ul.sto.care
{"url":"https://dl.sto.care/mjrxiq1odb","expiresAt":"2026-10-04T20:19:21.615Z"}

Full limits, status codes and error shapes are in the sto.care API documentation. If your file is bigger than 100 MB, 0x0.st is the better call and we would rather you used it than wasted a request finding out.