Guides

jstash vs JSONBin.io

Both keep JSON documents behind a small REST API, and both have a free plan. They suit different jobs. Here’s what each one does, when JSONBin is the better choice, and when jstash is.

Written by jstash, which makes one of the options compared here. Updated 4 October 2026.

Summary

• JSONBin has more features. Records are private by default on every plan. Pro adds version history and schema validation, and you can buy it today. Its API also works from browser JavaScript.
• JSONBin’s free plan is 10,000 requests in total. They’re credited once, not every month, and reads use them as well as writes. jstash Free gives 1,000 updates a day, every day, and public reads aren’t metered.
• jstash bins are simpler, and public. One JSON document at a URL, written from a server, script or CI, and read from any website. Your first one needs no account. Private bins need Pro, and there’s no version history.
• Saving each signed-in person’s data from a web page? Don’t put a key in the page, with either service. jstash Apps uses the person’s login token instead.

Side by side

The JSONBin facts below come from its own pages, linked in each cell, checked on 4 October 2026. The jstash facts come from our docs and pricing.

The free plans: credited once, or every day

JSONBin’s free plan gives you 10,000 requests when you sign up. Its pricing page says they’re “credited only for once”. When they’re gone, they don’t come back, and you can buy more only after upgrading to Pro. Creating, reading, updating and deleting all use requests, though reads in JSONBin’s own dashboard don’t count. Free records can be up to 100 KB, and you get 1 collection.

jstash Free resets every day at 00:00 UTC: 1,000 updates and 100 new bins a day, with up to 100 bins of 100 KB each and 10 MB in total. Reading a public bin by its URL isn’t metered on any plan. See all limits.

The difference shows with anything that writes on a schedule. A job that saves every 5 minutes makes 288 writes a day. That fits in jstash Free every day. On JSONBin Free it would use up the 10,000 requests in about 35 days, sooner if it reads too.

If you only change a document now and then, it matters less. 10,000 requests can last a long time.

Use JSONBin when…

• You want old versions. JSONBin Pro can keep up to 1,000 versions of each record, and the read API can fetch any of them. jstash keeps none: a replaced document is gone.
• Your data must be private on a free plan. JSONBin records are private by default on every plan, and reading one needs a key. jstash bins are public on Trial and Free; private bins need Pro.
• You want some structure. Collections group records and list them. On Pro you can attach a schema to a collection, so records that don’t match it are refused. JSON Path reads just part of a record. jstash has none of this: a bin is one document, read and replaced whole.
• You need to pay for more today. You can buy JSONBin Pro now, and requests you buy “never expire”. jstash Pro is invite-only, and no new invites are going out yet.
• You need bigger documents. JSONBin Pro takes records up to 1 MB, or 10 MB with XL Bins. XL Bins is early access, and JSONBin doesn’t recommend it for production yet. jstash allows 100 KB on Free and 1 MB on Pro.
• A throwaway prototype writes straight from the page. JSONBin turns on CORS for every endpoint, so browser JavaScript can create and update records. For this, JSONBin suggests an Access Key limited to the actions you need, not the Master Key. Anyone who opens the page can use that key too, so keep it to demos with nothing private in them.
• You don’t use GitHub. JSONBin accounts can sign in with Google and others. jstash accounts sign in with GitHub only.

Use jstash when…

• You want to start with no account. One request with no key returns a URL. The bin lasts 7 days; sign in with GitHub and claim it to keep it.
• Something writes on a schedule. A script, cron job or CI run that updates a document many times a day fits Free’s 1,000 updates a day, which reset every day. The API key stays on the server or in CI.
• Lots of people read it. A status file, a price list or a widget’s settings, read by every visitor to your site. Any website can fetch() a public bin with no key, and those reads aren’t metered. After an update, a browser can see the old copy for up to 5 minutes.
• More than one thing writes the same document. Send the last ETag as If-Match. If something else saved first, you get 412 and nothing is overwritten. See updating safely.
• Each signed-in person needs their own data. That’s jstash Apps, below.

# A first bin, with no account. Keep the edit_token: it’s shown once.
curl -d '{"hello":"world"}' https://api.jstash.app/v1/bins

Per-user data in a frontend app

A quick way to add cloud saving to a small web app is to call JSONBin straight from the page. To write, the page needs a key, so the key ends up in index.html or its JavaScript:

// In the page. Anyone who opens it can copy this key.
await fetch('https://api.jsonbin.io/v3/b/<BIN_ID>', {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/json',
    'X-Master-Key': '<YOUR_API_KEY>',
  },
  body: JSON.stringify(data),
});

Anything in a web page is public. Anyone can copy the key from the browser’s developer tools. JSONBin’s docs warn that a Master Key in a frontend “might end up exposing your key to other users which may carry any operation on your JSONBin records”. With the Master Key, that means reading, overwriting or deleting every record in your account.

JSONBin’s Access Keys narrow this, but don’t close it. A key can be limited to some actions, like only reading bins. But if the page can save, the key in it can save, for anyone who copies it. And keys belong to your account, not to each person using your app, so a key can’t keep one person’s data from another.

What jstash does instead

jstash bins won’t let you do this. The bins API refuses browser JavaScript from other websites, on purpose, so an API key or edit token never has a reason to be in a page. Bins are for data that a server, script or CI writes and everyone reads.

For each signed-in person’s own data, use jstash Apps. Your app keeps its login (Clerk, Supabase Auth, Firebase Auth or Sign In With Google), and the page sends the person’s login token. jstash checks the token, then reads or writes only that person’s documents. There’s no key in the page and no rules to write.

// In the page. No key: the signed-in person’s own login token.
const JSTASH = 'https://api.jstash.app/v1/apps/app_…/me'; // from your jstash dashboard

await fetch(`${JSTASH}/settings`, {
  method: 'PUT',
  // Clerk here. Supabase and Firebase send their own token the same way.
  headers: { Authorization: `Bearer ${await Clerk.session.getToken()}` },
  body: JSON.stringify(data),
});

• Free: 1 app with up to 100 people, each with up to 200 documents of 100 KB, and 100 saves per person a day. See all limits.
• Only your websites. Each app accepts browser requests from up to 5 website addresses you list, plus localhost while you develop.
• Per person only. No shared data, no search and no live sync, and jstash gives you no way to read your users’ documents.

No login in your app, and people share the data, like a family planner or a club’s list? Neither option fits well. A JSONBin key in the page leaves the data open to anyone, and jstash Apps needs a signed-in person. Keep the key in a small serverless function that checks each request, or use a database with access rules. How to save JSON from a frontend without exposing an API key covers both.

What jstash doesn’t do

• No backups or version history. A replaced or deleted document can’t be recovered. Keep your own copy of anything that matters.
• No SLA or uptime promise.
• No private bins on Free. Anyone with a public bin’s URL can read it, so don’t put secrets or personal data in one.
• No bin writes from browser JavaScript on other websites. Write from a server, script or CI.
• No queries, collections, schemas or partial updates. A bin is one document, read and replaced whole.
• No paid plan you can buy yet. Pro will be US$5 a month at launch. Until then it’s invite-only, and no new invites are going out.
• GitHub sign-in only for jstash accounts.
• Apps is for each person’s own data. It works with Clerk, Supabase, Firebase and Google logins only. No shared data, search or live sync, and no admin view of your users’ documents.
• No sensitive data. Don’t store health or similar sensitive personal data anywhere in jstash.

Which to pick

Neither one is a database. If you need queries, data people share with sign-in, or an admin view of your users’ data, use one.

More guides

• How to save JSON from a frontend without exposing an API key
• How to save user data in a static website
• How to add per-user cloud storage to a Clerk app
• localStorage vs cloud storage for small web apps
• How to add a database to a static website — and when you don’t need one