The Ultimate Toolkit for Debugging APIs
Essential free tools for debugging REST APIs: format JSON, decode JWTs, test regex, verify hashes, and diff API responses. All browser-based, no install.
Debugging APIs Without a Full Toolchain
Postman weighs in at 400 MB on disk. Insomnia asks for an account before you can create a collection. curl is fast and scriptable, but a 3,000-line JSON response piped through jq still leaves you squinting at a terminal window, scrolling vertically through nested objects without syntax highlighting.
For roughly 80 percent of API debugging tasks, a full toolchain is overkill. Most debugging sessions boil down to four activities: inspecting response payloads, validating data formats, decoding tokens embedded in headers, and comparing the output of two requests to spot what changed. A handful of browser-based tools handle each of these faster than any desktop client.
The tools below process data entirely in your browser's JavaScript runtime. Paste an API response, a JWT, or a raw response body and the result appears instantly. No upload, no account, no installation.
Format and Validate JSON: The Starting Point
The most common API debugging flow starts the same way: you hit an endpoint, the server returns a 200 with a minified JSON body, and you need to understand the structure before you can decide whether the response is correct.
Paste the response into the JSON Formatter. It pretty-prints with configurable indentation so nested objects, array lengths, and unexpected null values jump out visually. A response that looked like a wall of brackets and braces becomes a scannable outline.
Concrete workflow: you are debugging a user profile endpoint that should return name, email, and preferences. The formatted output shows a preferences object with 15 keys you did not expect. You scroll through the formatted tree and spot stripe_customer_id and last_four_digits nested inside preferences. The API is leaking billing data it should not expose. Without formatting, those fields were buried in a single-line blob you would never have noticed.
If the formatted output looks garbled or the tool produces an error instead of pretty output, the response body is probably malformed JSON. Switch to the JSON Validator. It scans the input and reports the exact line and column of the first syntax error, with a description of what went wrong. Missing commas, unquoted keys, trailing commas, and mismatched brackets each get a specific error.
Concrete workflow: your mobile app's API client throws a parse error on a response that the server logs show as 200 OK. You copy the raw response body from the server log into the JSON Validator. It reports "Unexpected token } at line 142, column 3." You check the source code for the endpoint and find that a conditional block sometimes leaves a trailing comma in a generated JSON array. The validator told you exactly where to look.
Format and validate as a two-step sequence: validate first to confirm the structure is syntactically sound, then format for readability. Formatting invalid JSON produces misleading output.
Decode JWTs Without a Library
APIs that use token-based authentication embed JWTs in Authorization headers, response bodies, or cookies. When something goes wrong with authentication, you need to inspect the token's contents without writing a decode script or installing a JWT CLI.
The JWT Decoder splits the token into its three dot-separated segments and Base64url-decodes the header and payload. You see the signing algorithm (HS256, RS256, ES256), the token type, the subject claim, the expiration timestamp, the issued-at time, and every custom claim your auth service attaches.
Concrete workflow: a user reports that they cannot access an endpoint that requires the editor role. You find the JWT in the Network tab of the browser's DevTools, copy it, and paste it into the decoder. The payload shows "roles": ["viewer"]. The token was issued for a viewer, not an editor. The bug is not in the endpoint's authorization logic. It is in the token issuance: the user was assigned the wrong role at login.
Concrete workflow: your CI pipeline starts failing with 401 errors on an internal API. You copy the service account JWT from the CI environment variables, decode it, and check the exp claim. The expiration timestamp is three days in the past. Someone rotated the service account credentials but did not update the CI variable. You rotate the token and the pipeline passes.
The decoder deliberately does not verify the signature. Signature verification requires the server's secret key or public key, and it is the server's responsibility at request time. What the decoder shows is what every party who handles the token can see: the payload is not encrypted, just encoded. This is why you should never put secrets in JWT claims.
Verify Hashes and Checksums
APIs that return file digests, request body hashes, or checksums need verification. The client documentation says the response body should produce a SHA-256 hash of abc123.... Did it?
The Hash Calculator computes MD5, SHA-1, SHA-256, and SHA-512 digests from text input or file uploads. For text input, paste the response body and select the algorithm. For file uploads, the hashing runs locally in the browser using the Web Crypto API. The file stays on your machine.
Concrete workflow: you are integrating with a payment processor's webhook API. The documentation says to compute a SHA-256 HMAC of the request body using a shared secret, and the result must match the X-Signature header. You copy the raw webhook body from your test log, paste it into the Hash Calculator with SHA-256 selected, and compare the output against the signature. They match. The webhook is authentic.
Concrete workflow: a file storage API returns a Content-MD5 header with each uploaded file. You download the file, drag it into the Hash Calculator in file mode with MD5 selected, and compare the output against the header value. The hashes match, confirming the file was not corrupted during transfer.
For security-sensitive contexts, prefer SHA-256 or SHA-512. MD5 and SHA-1 are broken for cryptographic purposes and should only be used for non-security integrity checks like detecting accidental corruption during file transfer.
Encode and Decode Payloads
APIs encode data in transit using several standard encodings. Base64 for binary data embedded in JSON payloads. URL encoding for query parameters. HTML entities in response bodies that contain user-submitted content.
The Base64 Encoder/Decoder handles standard Base64 and the URL-safe Base64url variant. Standard Base64 uses + and / with = padding. Base64url uses - and _ without padding and is the encoding used inside JWTs and URL-safe contexts.
Concrete workflow: an API endpoint expects a request body where one field is a Base64-encoded binary blob. You type the raw test value into the encoder, select Base64, copy the output, and paste it into your request. The alternative is opening a terminal and running echo -n piped to base64, which adds a trailing newline unless you remember the -n flag.
Concrete workflow: you are debugging a search endpoint where the query parameter ?q=hello+world returns different results from ?q=hello%20world. You paste both into the URL Encoder/Decoder and confirm they decode to the same string. The difference is in how the server parses the plus sign, which many frameworks interpret as a space. You standardize on percent-encoding and the bug disappears.
The HTML Escape/Unescape Tool decodes HTML entities in API responses that return HTML fragments. A response containing <script>alert(1)</script> becomes readable as <script>alert(1)</script>. This is useful for auditing API responses that embed user-generated content to check whether input sanitization is working.
Test Regex Patterns Against Real Data
APIs sometimes return unstructured or semi-structured text. Log output, error messages concatenated into a single string, raw HTML from a scraping endpoint. Extracting specific values from these responses requires regex, and writing regex without real-time feedback against the actual data is slow and frustrating.
The Regex Tester highlights matches in real time as you type both the pattern and the test string. You see exactly which substrings your capture groups are pulling in, whether the quantifiers are matching too much or too little, and whether edge cases like empty strings or special characters are handled.
Concrete workflow: an API returns error messages in a format like [2024-05-30 14:22:01] ERROR: Connection refused on host db-primary (retry 3/5). You need to extract the timestamp, the error message, the host, and the retry count from a log that is delivered as a single text field. You paste a representative sample into the Regex Tester and build the pattern piece by piece. After five iterations, you have ^\[([^\]]+)\]\s+ERROR:\s+(.+?)\s+on\s+host\s+(\S+)\s+\(retry\s+(\d+)/(\d+)\)$ with five capture groups, each verified against the test data.
Concrete workflow: you need to find every URL in a large HTML response body to build a link checker. You paste the response into the Regex Tester, start with a basic URL pattern, and immediately see that it misses protocol-relative URLs (//cdn.example.com) and URLs wrapped in Markdown syntax. You iterate until the pattern catches all the variants present in your actual data.
Compare API Responses Across Environments
An endpoint worked correctly yesterday in staging. Today in production, the response is different. What changed?
Diff the two responses with the Diff Checker. Paste the staging response on the left, the production response on the right. The tool highlights added, removed, and changed lines at both line-level and word-level granularity.
Concrete workflow: a user reports that their profile page shows a different set of permissions after the latest deploy. You call the profile endpoint in staging and production, copy both JSON responses, and format them through the JSON Formatter. Then you paste both into the Diff Checker. The word-level diff highlights that the permissions array in production is missing "can_export_csv" but staging has it. A feature flag was not toggled on in production.
Concrete workflow: you are upgrading an internal API from v1 to v2. The response schema should be backward compatible for the fields your front end consumes. You call both versions with the same input parameters, format both responses, and diff them. The diff shows three new fields in v2 that your front end does not need and one renamed field (user_id became userId). The rename is a breaking change. You catch it before deploying.
For structured diffing, always format both JSON payloads before comparing them. Comparing minified JSON produces a single-line diff that shows the entire line as changed, even if only one field's value differs. Formatted JSON yields line-by-line differences that highlight exactly which fields changed.
Decode and Inspect URL Query Strings
Complex APIs sometimes embed structured data in query strings using nested encodings, especially in redirect URLs and OAuth flows. A URL like https://api.example.com/callback?state=eyJ1c2VyIjoiYWJjIiwicmV0dXJuIjoiaHR0cHM6Ly9hcHAuZXhhbXBsZS5jb20ifQ%3D%3D contains a Base64-encoded JSON object that is itself URL-encoded.
The URL Encoder/Decoder decodes the percent-encoded characters to reveal the raw Base64 string. Then the Base64 Encoder/Decoder decodes the Base64 to reveal the JSON object inside. The JSON Formatter formats it for readability.
Concrete workflow: you are debugging an OAuth redirect loop. The state parameter is present in every redirect but you cannot tell whether it is being mutated. You decode each step's state parameter and diff the decoded payloads. The state is unchanged. The loop is caused by a cookie not being set, not by state corruption. You found the real bug instead of chasing a red herring.
The Toolkit Runs in Your Browser
Every tool described here processes data entirely in your browser's JavaScript runtime. The JSON formatter parses and re-serializes using JSON.parse and JSON.stringify. The JWT decoder splits on dots and runs atob. The regex tester uses the browser's native RegExp engine and highlights matches by manipulating the DOM. The diff checker implements the Myers diff algorithm in JavaScript. The hash calculator calls the Web Crypto API's SubtleCrypto.digest().
The practical upshot: your API responses, authentication tokens, proprietary data, and configuration values never leave your machine. You can paste a production JWT, a customer's PII-laden API response, or your company's internal endpoint schema into any of these tools without exposing it to a third-party service.
Try the toolkit: every tool mentioned here runs locally in your browser. Open the full tools list to see all available tools organized by category. Paste a real API response into the JSON Formatter right now to see it in action. No account, no install, no data leaving your machine.