Jqbin

Jqbin keeps the filter and the JSON in the URL instead of a server-side gist, and shows results without a Run button. That's the short pitch against play.jqlang.org, the official jq playground from the jqlang/jq repo. Picking a jq playground is mostly a question of which design choices the author made, so the longer version is below.

How jq playgrounds are normally built

A jq playground does four things: take JSON, take a filter, run jq, show output.

The default architecture, going back to jqplay.org in 2014, was a server-side jq invocation behind a small Go or Sinatra wrapper. You typed in a textarea, hit Run, the server forked a jq process, and returned the result as plain text. jqplay.org still works that way. You get the same jq binary you have installed locally, but every keystroke costs an HTTP round-trip, which is why jqplay.org caps inputs and why teams who need to share filters often end up elsewhere.

The newer architecture, which play.jqlang.org adopted around 2022 and which we use, compiles jq itself to WebAssembly and runs it in the browser tab. The official build is jq.wasm from jqlang/jq, currently part of jq 1.8.x. Once loaded, every filter run is a synchronous call into linear memory, so feedback is a frame later, not a round-trip later.

Once you go WASM, four design choices are still open, and that's where playgrounds actually differ.

The four design choices that split the field

Execution timing. On-submit playgrounds wait for a button click or Cmd+Enter and run jq once. Real-time playgrounds re-run jq on every keystroke (debounced) and stream the output into the result pane. Real-time is what makes jq feel like a REPL instead of a form submission.

Share semantics. Earlier tools required a login plus a save action that wrote to a server-side store. URL-encoded sharing keeps the filter and the JSON inside the link itself, usually after an lz-string pass. The cap we hit in our build is roughly 90 KB of compressed payload before Chrome and Firefox start cutting the URL in the omnibox.

Persistence and identity. Some tools require an account. Some save anonymously with a short slug. Some keep all state in the URL and localStorage. Account-required tools win on multi-device sync; URL-only tools win on no-signup friction and on the operator never having custody of the user's data.

Scope creep. Several playgrounds bolt on cheatsheets, snippet libraries, and sponsored slots. The more bolted on, the harder it is to embed.

Where each competitor lands

Quick aside: should you ever pick a server-side playground over a WASM one in 2026?

Yes, in two cases: testing a custom-compiled jq with non-default flags, or on a corporate machine where the WebAssembly content security policy denies wasm-unsafe-eval. Otherwise, the WASM path is faster and quieter.

We ran every column below ourselves on the same 18 KB Stripe webhook payload, on the same Chrome 131 build.

play.jqlang.org is the closest peer and the one we measured against most often. It's the canonical playground published by the jq maintainers, so a filter that works there is the ground truth. We do one thing differently: real URL-only persistence. Their share button mints a server-side slug and bounces you to a /s/<id> page, so the share is opaque to email scanners and dies if the server goes away. We compressed the filter and the JSON straight into the query string with lz-string, so a Jqbin link is self-contained and grep-able.

jqkungfu is the prettiest of the bunch and has the best snippet library, but it asks for a login before you can save. jqplay.org is the historical reference, useful when you want to confirm what the old build does, and the only one in the table without real-time execution.

The trade-offs you inherit with Jqbin

The WASM module is around 4.2 MB compressed. On a fresh load with a cold cache, that's roughly a 600 ms to 1.2 second hit before the first filter can run. After that, warm loads are near-instant.

Because everything runs in the tab, large inputs hit a real ceiling. We tested up to 50 MB and it works, but interactivity drops off around 10 MB on mid-range hardware because every keystroke triggers a re-parse. We chose the keystroke-driven feedback loop because the median session, the kind we kept seeing in screen recordings, is iterating against a few hundred KB. Optimizing for the 50 MB case would have cost the snappy feel for everyone.

URL sharing has a hard practical cap around 90 KB compressed. Above that, the link is valid but breaks in mail clients and in Slack's preview unfurler. When you exceed it, Jqbin falls back to copying the JSON to the clipboard and shortens the URL to filter-only. The failure mode we kept hitting was a 200 KB Terraform state link that worked in Chrome but truncated in Outlook; the clipboard fallback was the cleanest fix.

Filter history isn't saved to a server. Local query history lives in localStorage and is per-device. If you want a filter you wrote yesterday on a different laptop, it's gone unless you saved a permalink.

If you only care about canonical jq behavior, should you use this or the official playground?

Use whichever is in front of you. Both run the same upstream jq 1.8 WASM build, so the output is identical. Jqbin is the better tool for sending a link to a coworker; the official playground is the better tool for filing a bug against jq itself, because the maintainers will recognize the URL.

There's no single best jq playground, only the one whose design trade-offs match your workflow today. For pasting a webhook into a tab, iterating for two minutes, and sending the result to someone, we built Jqbin to be that one.

Frequently Asked Questions