API Response Formatter

About This API Response Formatter

I built this tool because formatting API responses is one of the most common tasks in web development. Every time you call a REST API, query a GraphQL endpoint, or receive a webhook payload, you get raw data that needs to be readable before you can work with it. Browser network tabs show the raw response, cURL returns a single line of JSON, and server logs capture payloads without formatting. This tool takes that raw output and makes it human-readable.

The formatter auto-detects whether your input is JSON or XML based on the first non-whitespace character. JSON input is parsed, validated, and re-serialized with 2-space indentation. XML input is parsed using the browser's DOMParser, validated for well-formedness, and re-indented with consistent formatting. Both formats receive syntax highlighting that color-codes different data types for quick visual scanning.

How to Use This Tool

Using this formatter is straightforward. Copy the raw API response from any source, paste it into the input area, and click Format. The tool does the rest automatically. Here are some common sources where you might copy API responses from.

Browser Developer Tools

Open your browser's developer tools (F12 or Cmd+Option+I on Mac), go to the Network tab, find the API request, and click on it. The Response tab shows the raw response body. You can right-click and select "Copy response" to copy the entire payload. Paste it into this tool for formatted viewing with syntax highlighting.

cURL Output

When testing APIs from the command line, cURL returns raw response data. A typical call like "curl -s https://api.example.com/users" returns compact JSON on a single line. Copy that output and paste it here. For XML APIs, the same approach works. The formatter will detect the format and apply appropriate formatting.

Postman and Insomnia

API testing tools like Postman and Insomnia have built-in formatters, but you might need to share a formatted response with a colleague, paste it into documentation, or compare two responses side by side. This tool provides an independent formatting environment that works the same way regardless of your API testing tool.

Server Logs

Application logs often contain API request and response payloads, especially when debug logging is enabled. These payloads are typically compact (minified) to save log storage space. Copying a payload from a log file and formatting it here makes it readable for debugging.

Understanding JSON Formatting

JSON (JavaScript Object Notation) is the dominant data format for modern APIs. It represents structured data using two basic structures: objects (key-value pairs enclosed in curly braces) and arrays (ordered lists enclosed in square brackets). Values can be strings, numbers, booleans, null, objects, or arrays, allowing for deeply nested data structures.

JSON Indentation

This formatter uses 2-space indentation for JSON, which is the most common convention in the JavaScript system. Each nested level of objects and arrays adds two spaces of indentation, making the nesting structure visually clear. Some teams prefer 4-space or tab indentation. For JSON specifically, 2-space is the dominant standard used by tools like Prettier, ESLint, and the Node.js community.

JSON Syntax Highlighting Colors

The formatter uses a consistent color scheme for different JSON data types. Keys appear in pink/magenta, making them easy to distinguish from values. String values appear in yellow. Numbers appear in purple. Boolean values (true/false) appear in green. Null values appear in red. This color scheme is based on popular code editor themes and makes it possible to identify data types at a glance.

JSON Validation

When you click Format, the tool first attempts to parse the input as JSON using the browser's built-in JSON.parse() function. If the input is not valid JSON, an error message appears with details about the parsing error, including the position where the error was detected. Common JSON errors include missing commas between array elements, trailing commas after the last element (which are not valid in strict JSON), single quotes instead of double quotes, and unquoted keys.

Understanding XML Formatting

XML (Extensible Markup Language) is still widely used in enterprise APIs, SOAP services, RSS/Atom feeds, and configuration files. While JSON has become more popular for new APIs, many legacy systems and industry-standard protocols (banking, healthcare, government) continue to use XML.

XML Indentation

The formatter indents XML using tabs, with each nested element adding one tab of indentation. Opening tags increase the indent level, and closing tags decrease it. Self-closing tags maintain the current level. This formatting makes the hierarchical structure of XML documents immediately visible.

XML Syntax Highlighting

XML syntax highlighting uses pink/magenta for tag names, blue for attribute names, yellow for attribute values, and the default text color for element content. This distinction makes it easy to separate structure (tags and attributes) from content (text nodes).

XML Validation

The formatter uses the browser's DOMParser to parse XML. If the input is not well-formed XML (missing closing tags, improperly nested elements, invalid characters), an error message appears. Note that this is structural validation only; it does not validate against an XSD or DTD schema.

Working with Large API Responses

API responses can range from a few bytes to several megabytes. This tool handles large payloads efficiently because all processing happens in the browser's JavaScript engine, which is optimized for JSON parsing. However, there are some practical considerations for very large responses.

Performance with Large Payloads

JSON.parse() and JSON.stringify() are native browser functions written in C++, so they are extremely fast. A 1 MB JSON response can be parsed and reformatted in under 100 milliseconds. The tree view generation is slower because it creates DOM elements for each node, so for responses with thousands of nodes, the code view may be more responsive than the tree view.

Deeply Nested Structures

Some API responses have deep nesting levels (10+ levels). The depth statistic shown below the formatter tells you the maximum nesting level. Deeply nested structures can be difficult to navigate even when formatted. The tree view is particularly useful for deep structures because you can collapse branches that are not relevant to your current investigation.

Paginated Responses

Many APIs return paginated responses with metadata about the total count, current page, and next page URL. When debugging pagination, you often need to format and compare multiple pages of responses. Format each page separately and compare the pagination metadata to verify that the API is returning consistent cursors or page numbers.

Common API Response Patterns

REST API Responses

REST APIs typically return JSON with a consistent structure. Common patterns include a top-level object with "data" and "meta" keys, error responses with "error" and "message" keys, and collection responses with an array of items plus pagination metadata. Formatting the response reveals these structural patterns and makes it easy to verify that the API follows its documented schema.

GraphQL Responses

GraphQL APIs return JSON with a specific structure: a "data" key containing the requested fields, and optionally an "errors" key if any resolvers failed. The data structure mirrors the shape of the query, so the formatted response directly corresponds to the fields you requested. Formatting GraphQL responses helps verify that the data shape matches your expectations and that no errors occurred.

Error Responses

API error responses contain diagnostic information including error codes, messages, and sometimes stack traces or validation errors. Formatting error responses is important for debugging because the error details are often nested within the JSON structure. A common pattern is a top-level "errors" array where each error has a "code", "message", "field" (for validation errors), and "details" object.

Webhook Payloads

Webhook payloads from services like Stripe, GitHub, Twilio, and Shopify contain event data that your application processes. These payloads can be complex, with nested objects representing the event type, the affected resource, and any changes that occurred. Formatting the payload when debugging webhook handlers helps you understand the exact structure your handler code needs to parse.

API Response Debugging Workflow

Debugging API issues follows a pattern that this formatter supports at several steps. Here is a typical debugging workflow.

Step 1 - Capture the Response

Get the raw API response from your browser network tab, server logs, or by running a cURL command. Copy the entire response body, including any error messages or metadata.

Step 2 - Format and Inspect

Paste the response into this tool and click Format. Check the statistics to understand the size and depth of the response. Look at the formatted output for any obvious issues: null values where you expected data, unexpected array structures, or missing keys.

Step 3 - Explore with Tree View

Switch to the Tree view to drill down into nested structures. Collapse branches that are not relevant and expand the ones that contain the data you are investigating. The tree view shows element counts for arrays and objects, which helps you verify that the expected number of items was returned.

Step 4 - Compare Responses

If you are comparing the response to a previous known-good response, format both and compare them side by side. Look for structural differences: new keys, removed keys, changed data types, or different array lengths. While this tool does not include a diff feature, formatting both responses consistently makes manual comparison much easier.

JSON vs XML for APIs

The choice between JSON and XML for API responses depends on the use case, industry requirements, and existing infrastructure. Here is a comparison of the two formats from a practical perspective.

Parsing Speed

JSON parsing is faster than XML parsing in every major programming language. JavaScript engines have native JSON.parse() that runs at near-native speed. XML parsing requires a full DOM parser or SAX parser, which is inherently more complex due to XML's richer feature set (namespaces, attributes, processing instructions, CDATA sections).

Payload Size

JSON is more compact than XML for the same data because it does not require closing tags and uses lighter syntax for collections. A typical JSON payload is 30-50% smaller than the equivalent XML representation. This matters for bandwidth-constrained environments like mobile applications and IoT devices.

Schema Validation

XML has mature schema validation through XSD (XML Schema Definition) and DTD (Document Type Definition). JSON has JSON Schema, which is widely supported but less mature than XSD. For industries that require strict contract-first API design (healthcare HL7, banking ISO 20022, government), XML's schema capabilities are still preferred.

Human Readability

Both formats are human-readable when properly formatted, which is exactly what this tool provides. JSON is generally considered easier to read because of its lighter syntax. XML's verbosity (opening and closing tags for every element) can make large documents harder to scan visually.

Security Considerations for API Data

API responses often contain sensitive data including authentication tokens, user personal information, payment details, and internal system identifiers. This tool is designed with privacy in mind.

All processing happens in your browser using JavaScript. No data is sent to any server. The page does not write to local storage or session storage. There are no third-party analytics scripts that could capture your input. This means you can safely format API responses that contain production data, API keys, or customer information.

However, be aware that your browser may store data in other ways. The input text may appear in your browser's autofill suggestions. If you use a browser extension that captures form data, it might record the input. For highly sensitive data, consider using a private/incognito browser window.

Integration with Development Tools

Browser Extensions

Several browser extensions format JSON responses automatically when you navigate to a JSON URL. While these are convenient, they only work for responses displayed directly in the browser. They do not handle responses copied from network tabs, logs, or other sources. This web-based tool fills that gap.

VS Code and Editor Plugins

Code editors have JSON formatting built in (VS Code's "Format Document" command). However, when you are debugging an API issue and need to quickly format a response from a log file or Slack message, opening a file in your editor is slower than pasting into this web tool.

Command-Line Tools

jq is the standard command-line JSON processor. It can format, filter, and change JSON data. xmllint formats and validates XML. These tools are excellent for scripting and automation but require installation and command-line fluency. This web tool provides the same formatting capability with a visual interface.

API Testing Platforms

Postman, Insomnia, Thunder Client, and HTTPie all include response formatting. This standalone tool is useful when you need to format a response outside of your testing platform, when you are working on a machine without your usual tools installed, or when you need to share a formatted response with someone who does not use the same testing platform.

Understanding Response Statistics

The formatter provides six statistics about your API response that help you understand its structure and characteristics.

The format indicator tells you whether the input was detected as JSON or XML. The size shows the raw payload size in bytes or kilobytes. Monitoring response size helps identify API endpoints that return more data than necessary, which can impact application performance. The line count shows how many lines the formatted output spans, giving a sense of the response's complexity.

The depth shows the maximum nesting level. A depth of 1 means a flat object. A depth of 5 means objects nested 5 levels deep. APIs with a depth greater than 7-8 levels may benefit from restructuring. The key count shows the total number of unique keys in the JSON structure, and the array count shows how many arrays are present. These metrics help you understand the shape of the data before writing parsing code.

Common JSON Errors and How to Fix Them

Trailing Commas

JavaScript allows trailing commas in arrays and objects, but strict JSON does not. A trailing comma after the last element like {"name": "John", "age": 30,} will cause a parse error. Remove the comma after the last element.

Single Quotes

JSON requires double quotes for both keys and string values. Single quotes like {'name': 'John'} are not valid JSON. Replace all single quotes with double quotes.

Unquoted Keys

JavaScript allows unquoted object keys, but JSON does not. {name: "John"} is valid JavaScript but not valid JSON. All keys must be wrapped in double quotes: {"name": "John"}.

Comments

JSON does not support comments. Some configuration file formats (like JSONC used by VS Code settings) allow comments with // syntax, but standard JSON parsers will reject them. Remove all comments before formatting.

Undefined Values

JavaScript's undefined value does not exist in JSON. If your data contains undefined, it will either be omitted during serialization or cause a parse error. Replace undefined with null or remove the key entirely.

API Response Best Practices

If you design APIs as well as consume them, formatting your own responses helps you evaluate their usability. Well-designed API responses have consistent structure, meaningful key names, appropriate data types, and manageable nesting depth. Here are practices I follow when designing API responses.

Consistent Response Envelopes

Use the same top-level structure for all endpoints. A common pattern is a response envelope with "data", "meta", and "errors" keys. The "data" key contains the actual response payload (an object for single resources, an array for collections). The "meta" key contains request metadata like pagination info, request IDs, and timestamps. The "errors" key contains an array of error objects when the request fails.

Meaningful Key Names

Use descriptive, consistent key names. Prefer "created_at" over "cAt" or "date1". Use either snake_case or camelCase consistently across all endpoints. The JSON specification does not mandate a naming convention, but consistency within an API is important. Most REST APIs use snake_case, while many JavaScript-focused APIs use camelCase.

Appropriate Data Types

Use the correct JSON data type for each value. Dates should be ISO 8601 strings ("2024-01-15T10:30:00Z"). Monetary amounts should be integers in the smallest currency unit (cents) or strings with fixed decimal places to avoid floating-point precision issues. Boolean flags should be actual booleans (true/false), not strings ("true"/"false") or integers (0/1).

Pagination Metadata

Collection endpoints should include pagination information. Common patterns include cursor-based pagination (with "next_cursor" and "prev_cursor" fields) and offset-based pagination (with "page", "per_page", "total", and "total_pages" fields). Cursor-based pagination is preferred for large datasets because it handles insertions and deletions gracefully.

Error Response Design

Error responses should include enough information for the API consumer to understand and fix the issue. A well-designed error response includes an HTTP status code, an application-specific error code, a human-readable message, and for validation errors, a list of field-level errors with the field name and specific error for each.

Working with Specific API Platforms

Stripe API Responses

Stripe API responses use a consistent envelope with "object" type identifiers, expandable references, and list pagination. A typical Stripe response includes "id", "object" (the resource type like "charge" or "customer"), and nested objects for related resources. When debugging Stripe webhooks, formatting the event payload reveals the nested structure of the event data, which can be several levels deep for complex events like subscription updates.

GitHub API Responses

GitHub's REST API returns JSON with link-based pagination (in HTTP headers, not the response body). GraphQL responses from GitHub follow the standard GraphQL envelope. Formatting GitHub API responses is useful when building integrations, CI/CD pipelines, or GitHub Apps. The response structure varies significantly between resources (repositories, pull requests, issues, workflows), so formatted viewing helps you understand the available fields.

AWS API Responses

AWS APIs return both JSON and XML depending on the service. S3 APIs return XML, while most modern AWS services return JSON. AWS response structures often include request metadata (RequestId, HTTPStatusCode) alongside the actual data. Formatting AWS responses helps when debugging Lambda functions, API Gateway integrations, and Step Functions workflows.

Google Cloud API Responses

Google Cloud APIs follow the API design guide with consistent error handling, pagination tokens, and field masks. Response structures use camelCase key names and include "nextPageToken" for pagination. Formatting Google Cloud responses is useful when building integrations with services like BigQuery, Cloud Functions, or Pub/Sub.

API Response Size Optimization

API response size directly impacts application performance, especially on mobile networks. Formatting a response and examining its structure can reveal opportunities for size optimization.

Identifying Unnecessary Fields

Format the response and review each field. Are all fields used by the client? Many APIs return complete resource representations when the client only needs a few fields. GraphQL solves this by letting clients specify exactly which fields to return. For REST APIs, field selection parameters (like "?fields=id,name,email") can reduce response size significantly.

Reducing Nesting Depth

Deeply nested responses are harder to parse and larger than flattened alternatives. If a response has objects nested 6+ levels deep, consider flattening the structure. Instead of deeply nested objects like user.profile.settings.notifications.email.enabled, use a flatter structure with composite key names.

Compression

JSON and XML compress well because they contain repeated key names and structural characters. Enabling gzip or Brotli compression on API responses typically reduces transfer size by 60-80%. The minify button in this tool removes whitespace, which achieves a smaller reduction (typically 10-30%) but works at the application level rather than the transport level.

Measuring Response Sizes

The size statistic in this tool shows the raw payload size. Compare the formatted size to what you expect. A user profile endpoint returning 50 KB per request is likely including too much data. A paginated list returning 2 MB per page is probably sending too many items or too many fields per item. Use this formatter to inspect the response and identify what is contributing to the size.

JSON Path and Data Extraction

JSON Path is a query language for extracting values from JSON documents, similar to XPath for XML. While this tool does not include a JSON Path evaluator, understanding JSON Path helps you describe the location of data within a formatted response.

A JSON Path expression like "$.users[0].profile.location" means: start at the root ($), access the "users" key, take the first array element ([0]), access the "profile" key, and return the "location" value. When you format a response in this tool, the indentation shows you the exact nesting path to any value.

Common JSON Path expressions include $.data for accessing the main payload, $.meta.pagination for pagination info, $.errors[*].message for extracting all error messages, and $..id for finding all "id" fields at any depth (recursive descent). Understanding these patterns helps you write extraction code that correctly navigates complex response structures.

XML-Specific Formatting Considerations

Namespaces

XML namespaces (xmlns attributes) add complexity to XML formatting. Namespace declarations can be verbose, and namespace-prefixed element names affect readability. This formatter preserves namespaces as-is and highlights them in the syntax highlighting. When working with SOAP APIs, the namespace declarations are important for understanding which schema defines each element.

CDATA Sections

XML CDATA sections contain text that should not be parsed as XML markup. They are commonly used for embedded HTML, JavaScript, or other content that contains characters that would be treated as XML syntax. The formatter preserves CDATA sections and displays them in the formatted output.

Processing Instructions

XML processing instructions (like the XML declaration <?xml version="1.0"?>)" provide metadata about the document. The formatter keeps processing instructions on their own lines at the beginning of the document.

SOAP Envelope Formatting

SOAP APIs use XML with a specific envelope structure: Envelope, Header (optional), and Body elements. Formatting a SOAP response reveals the envelope structure and makes it possible to navigate to the actual data within the Body element. The Header element may contain authentication tokens, message IDs, and routing information that are relevant for debugging.

Real-World Debugging Scenarios

Missing Data in UI

When a frontend component is not showing expected data, format the API response to verify that the data exists in the payload. Check key names for typos (case sensitivity matters in JSON), verify that the data is in the expected location within the nesting hierarchy, and confirm that values are the expected data types (number vs string, array vs object).

Authentication Failures

API authentication errors often return detailed error information in the response body. Format the error response to see the exact error code and message. Common patterns include "invalid_token", "token_expired", "insufficient_scope", and "rate_limit_exceeded". The formatted response may also include a "retry_after" value or a URL for re-authentication.

Rate Limiting

When you hit an API rate limit, the response typically includes information about your current usage, the limit, and when the limit resets. Format the response to extract the "retry_after" or "reset_at" values. This information is sometimes in HTTP headers rather than the response body, but many APIs include it in both places.

Data Type Mismatches

A common bug source is data type mismatches between the API response and the client's expectations. Format the response and check: Is the "amount" field a number (42.50) or a string ("42.50")? Is "count" returned as 0 (number) or null? Is "tags" an empty array ([]) or null when there are no tags? These differences cause subtle bugs in client code.

API Response Caching and Performance

Understanding the structure of API responses helps you make informed caching decisions. When you format a response, you can see which parts change frequently and which remain stable. This information guides your caching strategy.

Identifying Cacheable Responses

Format the response and look for timestamps, request IDs, and other per-request metadata. If the "data" portion is identical across requests but the "meta" portion changes (different request_id, different timestamp), you can cache the data portion while ignoring the metadata. Responses that include a "last_modified" or "etag" field in the data are designed for conditional caching.

Response Normalization

When caching API responses on the client, normalizing the data (flattening nested structures into a lookup table by ID) is more fast than caching the raw response. Formatting the response reveals the relationships between entities (a user has orders, each order has items) and helps you design the normalization schema. Libraries like normalizr use schema definitions to flatten nested API responses automatically.

Stale-While-Revalidate Patterns

The stale-while-revalidate caching strategy serves cached data immediately while fetching fresh data in the background. Format both the cached and fresh responses to compare them. If the structure is identical and only values changed, your UI update code can be simple. If the structure changed (new fields added, fields removed), you need more defensive parsing code.

Testing API Responses

API response formatting is an important step in testing workflows. When writing integration tests, you need to verify that API responses match expected structures and values.

Snapshot Testing

Many testing frameworks (Jest, pytest-snapshot) support snapshot testing, where the expected response is stored as a file and compared against actual responses. Format the expected response before saving it as a snapshot. Formatted snapshots produce meaningful diffs when the response changes, making it clear exactly which fields changed and how.

Contract Testing

API contract testing tools like Pact verify that API producers and consumers agree on the response structure. Format example responses from your contract definitions to review them. A well-formatted contract makes it easy for both the API team and the consumer team to verify that the agreed structure meets their needs.

Response Schema Validation

JSON Schema validation ensures that API responses match a defined structure. Format example responses alongside their JSON Schema definitions to verify coverage. Check that required fields are present, data types are correct, and enum values are valid. This formatter's statistics (key count, depth, array count) give you a quick sense of whether the response structure is within expected bounds.

From API Response to Application State

In frontend applications, API responses are transformed into application state. Formatting the response helps you plan this transformation.

State Shape Design

Format the API response and compare it to your desired state shape. Modern state management (Redux, Zustand, Pinia) works best with normalized, flat state structures. The formatted response shows the nesting that needs to be flattened and the relationships that need to be extracted into lookup tables.

TypeScript Type Generation

From a formatted API response, you can derive TypeScript interfaces for your application. Each JSON key becomes a property, the value determines the type. Nested objects become nested interfaces. Arrays become typed arrays. Tools like quicktype can automate this, but reading the formatted response helps you verify that the generated types are correct and add appropriate optional markers for fields that might be null.

Data Transformation Functions

API responses often need transformation before display. Dates need formatting, monetary values need currency symbols, enum values need human-readable labels, and nested data needs to be flattened for table display. Format the response to understand the input structure, then write transformation functions that convert each field to its display format.

API Response Evolution

APIs evolve over time, and responses change as new fields are added, deprecated fields are removed, and structures are modified. Formatting responses from different API versions side by side reveals these changes.

Backward Compatibility

Well-designed APIs add new fields without removing existing ones. Format responses from version 1 and version 2 of an API to see what changed. New fields that did not exist in version 1 should have sensible defaults or be marked as optional. Removed fields should trigger deprecation warnings before being eliminated.

API Versioning Strategies

APIs handle versioning through URL paths (/v1/, /v2/), headers (Accept: application/vnd.api.v2+json), or query parameters (?version="2)." Regardless of the strategy, formatting responses from different versions helps you understand the migration path from one version to another and plan your client code updates accordingly.

Deprecation Detection

Some APIs include deprecation warnings in their responses. Format the response and look for fields like "deprecated_fields", "_warnings", or HTTP headers indicating upcoming changes. Catching these early gives you time to update your integration before the deprecated fields are removed.