📡 We check My JSON Server (and 36 other public mock/testing services) with a plain GET every 30 minutes — see the live status page.

My JSON Server alternative — your db.json hosted, with writes that actually persist

My JSON Server is a lovely idea from typicode — the developer the whole category owes: they built json-server and JSONPlaceholder. The pitch: put a db.json in a public GitHub repo and my-json-server.typicode.com/<user>/<repo> serves it as a REST API. No install, no deploy, and your fixture data is versioned in git. Genuinely clever.

Then you hit the walls — all verified hands-on against the live service (their own typicode/demo server), August 28, 2026:

Writes are faked. POST /posts answers 201 {"title":…,"id":4} — and GET /posts/4 immediately answers 404 with an empty {}. PUT echoes your change back, then the next GET shows the original. DELETE answers 200 and the record survives. Their homepage says so plainly: changes are faked and aren't persisted, "just like JSONPlaceholder". Your demo can render a list, but nothing you build against it can actually save.
You need a GitHub account and a public repo before anything works. "No registration" is true only if you already have GitHub. And every data change is a commit + push cycle — there is no API to change data (see above) and no UI.
Responses are cached for a minute (their stated limit), so even after you push, the API can keep serving the old data for up to ~a minute. Tight edit-refresh loops get confusing fast.
Everything is public. All servers are public and private GitHub repos aren't supported — anyone who knows user/repo can read your fixture data. Their homepage has promised private-repo support "later" since the beta began.
It's been "beta" since 2017, with the maker's own honest warning on the homepage: URLs may change, the service may be down, use at your own risk — and a pointer to install json-server locally if you need something reliable. The footer says © 2017-2019.

Mockbird speaks the same json-server dialect — same underlying idea, same query params — but the hosted API is writable and persistent, needs no GitHub repo, and changes are live instantly. Free, no signup, 10,000 requests/day per project.

Move your db.json in one pipe

Your db.json is already at a raw URL — pipe it straight into Mockbird's db.json import:

curl https://raw.githubusercontent.com/USER/REPO/main/db.json \
  | curl -X POST https://mockbird.mockbird.workers.dev/api/projects/import --data-binary @-

# → {"id":"…","adminKey":"…","resources":[{"name":"posts","records":3,…}],…}

(Older repos use master instead of main — typicode's own demo repo does.) Records arrive verbatim with their original ids. We ran exactly this against typicode/demo's db.json before publishing: posts and comments imported with ids intact, and the singular profile object became a 1-record collection (with a warning telling you so).

Same dialect, now writable

Every query idiom My JSON Server inherits from json-server works here too — these all ran against a live imported project before this page went up:

B=https://mockbird.mockbird.workers.dev/m/PROJECT_ID

curl "$B/posts/1"                        # single record
curl "$B/comments?postId=1"              # field filter
curl "$B/posts?_page=1&_limit=2"         # pagination
curl "$B/posts?_sort=id&_order=desc"     # sorting
curl "$B/posts?q=Post 1"                 # full-text search
curl "$B/posts/1/comments"               # nested route
curl "$B/comments?_expand=post"          # join the parent

And the part their server can't do at all:

# POST — and it's actually there afterwards
curl -X POST "$B/posts" -H 'content-type: application/json' \
  -d '{"title":"Post 4 — actually saved"}'
curl "$B/posts/4"
# → {"title":"Post 4 — actually saved","id":4}     (not a 404)

# PUT/PATCH stick, DELETE really deletes
curl -X PATCH "$B/posts/4" -H 'content-type: application/json' -d '{"title":"edited"}'
curl -X DELETE "$B/posts/4"

Want the git-versioned-fixtures workflow? Keep it.

The one genuinely great thing about My JSON Server is that your fixture data lives in version control. You don't lose that here: every Mockbird project ejects as a db.json at any time —

curl -o db.json https://mockbird.mockbird.workers.dev/m/PROJECT_ID/db.json
git add db.json && git commit -m "snapshot fixtures"

— so the flow becomes: edit data live through the API (or the dashboard's data browser), then commit the export when it's worth keeping. The file works verbatim with npx json-server db.json and with My JSON Server itself. For test-suite determinism there are also named server-side snapshots you can save and restore per scenario — no git round-trip at all.

My JSON Server → Mockbird translation

My JSON Server	Mockbird
Create GitHub repo → add db.json → push	One curl POSTs the same db.json (import) — or one click, no repo, no account
Edit data = commit + push + up-to-1-minute cache lag	Writes are live instantly via plain REST (or the dashboard data browser)
POST/PUT/PATCH/DELETE faked (nothing persists)	All writes persist; webhooks can fire on each one
`?_page/_limit`, `_sort/_order`, `q=`, filters, `_expand/_embed`, nested routes	Same params, same semantics — plus `_gte/_lte/_ne/_like` operator suffixes and `?select=`
All servers public (private repos unsupported)	Projects are unlisted by default + optional protected mode (Bearer JWT on every endpoint)
Static file only	Also: seeded realistic fake data, GraphQL, custom routes, `?mock_status/?mock_delay/?mock_chaos`, request inspector, OpenAPI/Postman/TS+Zod exports
Beta since 2017; homepage warns it may be down	Free while in beta too — but writes work, and we publish uptime checks

Where My JSON Server genuinely wins

Bias disclosed — this page is written by the Mockbird maker, and this service comes from the person whose json-server conventions we deliberately follow. Honest wins: if your team already lives in GitHub, data-in-the-repo is a real workflow — fixture changes go through pull requests, get reviewed, and the mock updates itself on merge with zero extra tooling. There's nothing to keep alive: no project ids, no admin keys, just a file. And for a read-only classroom demo, "fork this repo and you have your own API" is a beautiful onboarding move no hosted dashboard can match. If reads are all you need and your data already lives in git, it's a fine choice — the walls only appear the moment your app needs to save something, or your data shouldn't be public.

Start now

# your db.json, hosted and writable, in one pipe:
curl https://raw.githubusercontent.com/USER/REPO/main/db.json \
  | curl -X POST https://mockbird.mockbird.workers.dev/api/projects/import --data-binary @-

# no db.json handy? one curl seeds a whole fake backend:
curl -X POST https://mockbird.mockbird.workers.dev/api/projects \
  -H 'content-type: application/json' -d '{"name":"my api","preset":"blog"}'

Or try the shared demo with zero setup: curl https://mockbird.mockbird.workers.dev/m/demo/products/1

Facts checked hands-on Aug 28, 2026 against my-json-server.typicode.com/typicode/demo: POST → 201 id 4 → GET /posts/4 → 404 {}; PUT echo not persisted; DELETE 200 with record surviving; _page/_limit/_sort/_order/q/_expand/nested all working; homepage limits verbatim (faked changes, 1-minute cache, public servers only, private repos unsupported, beta warnings). If the service changes, re-check their site.

Full API reference in the docs. More guides: json-server, hosted · JSONPlaceholder alternative · CSV → REST API. Create your API →

⚡ Skip the terminal: this link creates a live, seeded blog backend in the dashboard — posts, comments, authors, real URL, no signup.