Help Centre

Standard JSON parse errors like Unexpected token at position 4471 tell you something is wrong at a character offset, but not where that is in your file. Jsonlook converts that position to a line and column number, and shows you the surrounding text with the error location highlighted.

For example, a trailing comma in {"name": "Alice",} produces "Line 1, column 20" instead of a raw position number. Common issues Jsonlook catches: trailing commas, missing quotes around keys, unescaped control characters, and mismatched brackets.

How to use it: Open the Paste JSON tab, paste your text, and click "Parse". The error location and a snippet from the surrounding text appear in the result panel.

This is surprisingly common. A server that crashes or encounters an internal error sometimes returns a 200 status with an HTML error page or a malformed body instead of the expected JSON. The client sees a 200 and assumes success, then fails when it tries to parse the body.

Jsonlook's URL inspection mode reveals the real picture: it reports the actual status code and the actual Content-Type header. If the server says Content-Type is application/json but the body is HTML, or if the status is 200 but the body is a JSON error object, Jsonlook flags it in the verdict.

How to use it: Open the URL tab, enter the endpoint URL, and click "Inspect". Read the verdict below the metadata.

There are two common reasons:

1. The server is behind Cloudflare. Jsonlook runs on a Cloudflare Worker. Cloudflare Workers cannot reach other Cloudflare-hosted origins — this is a platform restriction, not a problem with your URL. The input field on the URL tab warns about this. If you need to inspect a Cloudflare-hosted endpoint, you would need to test it from outside the Cloudflare network (for example, from a local terminal with curl).

2. The server is down or unreachable from the Worker's network. Jsonlook attempts a single fetch with no retries and no redirect following. If the server is unreachable, times out, or returns a network error, Jsonlook reports it as unreachable. This includes private (internal) IP addresses, which the Worker cannot connect to.

No. Jsonlook is stateless by design.

Pasted JSON text is parsed entirely in your browser using JavaScript's JSON.parse(). The text never leaves your computer — it is never sent to any server, never logged, never stored. It exists only in the browser's memory for the duration of the page session and is discarded when you close or reload the page.

URL inspection sends the URL you typed to the Jsonlook Worker via an HTTPS POST request. The Worker fetches the URL exactly once, performs no logging, uses no database, and retains no record of the request or response. The response body is returned to your browser for display and is not stored anywhere.

See the Privacy Policy for full details.

No. Jsonlook sends a single plain fetch with redirect: 'manual' and no custom headers, no cookies, no authentication. It cannot authenticate to any server. The URL inspector is designed for public endpoints only.

If you need to inspect a private API, you would need to replicate the inspection from a local tool (e.g. curl -v from your terminal, or a scripting language with the appropriate auth headers configured).

No. Jsonlook is a one-shot diagnostic tool. Every inspection is synchronous and stateless. There is no scheduler, no background checks, no email sender, and no alert system.

Scheduled re-checks and email alerts are listed as planned, but they are not built yet and there is no timeline for when or if they will ship. Jsonlook also has no email sender, so it cannot notify you of anything.

For monitoring, you would need a dedicated uptime or API monitoring service.