Share JSON via compressed URL
Generate a shareable URL that contains your JSON encoded directly in the hash. Uses gzip compression for smaller payloads. No server, no tracking — peer-to-peer sharing.
Your JSON is gzip-compressed in the browser, base64url-encoded, and placed in the URL hash (after #share=). The hash is never sent to any server. When someone opens the URL, JSONLab reads the hash, decompresses it, and loads the data automatically.
Serverless sharing with privacy by design
📦 Gzip compression
Your JSON is compressed with the browser's native CompressionStream API before being placed in the URL. A typical 10KB JSON payload often shrinks to 2–3KB in the URL.
🔤 URL-safe encoding
The compressed bytes are base64url-encoded (using - and _ instead of + and /), so the resulting URL is safe to paste into chat apps, emails, and markdown.
🤝 Peer-to-peer, no server
The data lives in the URL hash, which is never sent to a server. There's no database, no API endpoint, and no Terms of Service — just two browsers exchanging data through a link.
⚖️ Graceful size fallback
If your JSON exceeds the URL length limit (typically 30,000 characters after compression), the tool shows a clear warning suggesting the Download button instead. No silent truncation.
⚡ Auto-decode on load
When someone opens a share URL, JSONLab automatically reads the hash, decompresses the payload, and populates the input — no clicks required. The hash is then cleared from the URL.
🔒 100% private
Because the data is encoded in the URL itself and never transmitted, there's nothing to intercept or leak. Suitable for sharing sensitive JSON like internal API responses and configs.
Sharing JSON via URL — common questions
What is the size limit for shareable URLs?
JSONLab caps shareable URLs at 30,000 characters to stay within the URL length limits enforced by most browsers (typically around 32K). The data is gzip-compressed before encoding, so a typical 10KB JSON payload easily fits — JSON is highly compressible thanks to repeated key names and structural characters.
If your content exceeds the limit, the tool shows a clear warning suggesting you use the Download button instead. No silent truncation happens, so you never accidentally share partial data.
For very large JSON (multi-megabyte), consider hosting the file yourself and sharing a regular URL, or use a dedicated file-sharing service.
Is my JSON really private?
Yes. The data is encoded entirely in the URL hash — the part after the # character. Browsers never send the hash to the server when loading a page, so the JSONLab backend never sees your content. The only way to read the data is to open the URL in a browser.
You can verify this in your browser's DevTools Network panel: when you load a share URL, you'll see a request for share.html (or whatever tool you shared) without any payload. The hash is processed purely client-side.
Of course, anyone you give the URL to can decode it. Treat the URL like any other shared secret.
How does decoding work when someone opens the URL?
When someone opens a share URL, JSONLab's JL.url.readSharePayload() function reads the hash, decompresses it with the matching scheme (gzip via DecompressionStream or plain base64), and returns the original JSON string. The tool's input is then populated with the data.
After loading, the hash is cleared from the URL via history.replaceState, so the data is no longer visible in the address bar (though it's still in the input box for the user to see and edit).
No network request is made for the content itself — only the static page assets are loaded.
How long do share URLs last?
Share URLs last as long as the URL itself is accessible. Since the data is encoded entirely in the hash and nothing is stored server-side, the link works for as long as the JSONLab page is reachable. There's no expiration policy because there's no server to expire anything.
If JSONLab ever changes its encoding format, old share URLs may stop working. We're committed to maintaining backward compatibility for the existing gzip+base64url scheme.
For long-term archival, consider downloading the JSON file directly — it doesn't depend on JSONLab being available.
How does this compare to pastebin?
Pastebin stores your content on a server and gives you a short ID (like pastebin.com/abc123). The advantage is shorter URLs; the disadvantages are that your data lives on someone else's server, is subject to their Terms of Service, can be deleted or expired, and may be visible to the platform's operators.
JSONLab encodes your content directly into the URL hash, so there's no server-side storage, no expiry policy, and no Terms of Service to worry about. The trade-off is that URLs are longer than paste IDs, which is why we gzip-compress the data first.
For short snippets and quick sharing, JSONLab's URL approach is more private. For very large content, pastebin or a file-hosting service may be more practical.