"I need to store some JSON" can mean very different things. Settings for one user's browser. A list your whole team edits. Payloads a backend processes later. The right home depends on three questions:
- Who needs to read it? Only this browser, or other people and services too?
- How long must it last? Until the tab closes, or indefinitely?
- Do you want to run anything? Nothing at all, or a real database?
Only in this browser
localStorage stores strings, so you JSON.stringify on the way in and JSON.parse on the way out. It's synchronous, simple and limited to a few megabytes per site. It's ideal for preferences and drafts.
IndexedDB stores structured objects directly, handles much more data and works asynchronously. It's the better choice for offline-first apps, but the API is verbose, so most people use a wrapper library.
Both stay in one browser on one device. Nobody else can read the data, and clearing site data deletes it.
In your repository
A JSON file is perfect for content that ships with the app: config, seed data, translations. It isn't a place to save user input in production. Most hosting platforms deploy a read-only filesystem, and anything written at runtime is lost on the next deploy.
Shared, without running anything
A hosted JSON API gives you endpoints you can POST JSON to and GET back from anywhere: a browser, a phone, a script or another service. There's no schema to design and no server to run. That's the gap ReqRes fills:
curl -X POST https://reqres.in/api/collections/notes/records \
-H "x-api-key: YOUR_MANAGE_KEY" \
-H "Content-Type: application/json" \
-d '{"data": {"title": "First note", "pinned": true}}'
Each project gets collections (like tables) of JSON records, a read-only public key for browsers, a manage key for writes, and request logs. The free plan covers 250 requests a day, 3 collections and 100 records per project. It suits prototypes, demos, teaching, test fixtures and small internal tools.
Shared, in a real database
When the data matters long term, use a database:
- Document databases (MongoDB, Firestore) store JSON-like documents natively and scale well. You design indexes and access rules.
- Postgres with JSONB (for example on Supabase or Neon) lets you keep flexible JSON alongside relational tables, query inside it and index it. It's a strong default if you might need relations later.
The trade-off is setup and responsibility: schemas or rules, auth, backups and migrations.
Quick decision table
| You need | Use |
|---|---|
| Settings or drafts for one user in one browser | localStorage |
| Lots of data offline in the browser | IndexedDB |
| Fixed content that ships with the app | A JSON file |
| Data other people and services can read, with nothing to run | A hosted JSON API such as ReqRes |
| Long-lived product data with queries and relations | Postgres (JSONB) or a document database |
A common path is to start with a hosted JSON API while you find out whether the idea works, then move to a database once it does. Because a ReqRes collection is plain REST and JSON, you can read every record back over the same API and load it into your database when you move.
Using an AI coding assistant? Connect the ReqRes MCP server and it can create the project and collections for you.