GraphQL query schema (SDL) formatting and beautification tool | ZeroTools

The formatting feature for GraphQL queries and Schema Definition Language (SDL) in this tool is implemented using the official graphql 16.14.2 Lexer and Parser, replacing proprietary regular-expression string substitution.

This means it performs full syntactic parsing across GraphQL operations (Query, Mutation, Subscription), fragment definitions, and schema definitions, rather than relying on brittle delimiter approximations.

However, it specifically validates GraphQL syntax alone: it does not validate query fields, arguments, or fragment types against an underlying server schema, nor does it connect to a remote network endpoint or API.

In development workflows, GraphQL queries written inside frontend components frequently lose their indentation due to repeated editing, collaborative refactoring, or payload extraction.

In such cases, this tool allows you to instantly recover code readability directly in your browser without launching a heavy IDE, language server, or backend service.

In addition to executable document operations, the tool formats Schema Definition Language (SDL) documents that specify types, fields, inputs, enums, and unions.

While executable queries and schema type definitions serve distinct roles across the stack, both share GraphQL's formal grammatical token structure and brace-delimited hierarchy.

The official lexer breaks the source into structured tokens, allowing the formatter to cleanly reconstruct indentation according to your chosen setting of 2 or 4 spaces.

Crucially, raw string literals and multiline block strings are preserved using lexer source offsets rather than parser reconstruction alone, keeping escaped triple quotes inside block strings and intentional trailing whitespace intact while retaining all code comments in their proper syntactic positions.

Any modification to source text or indentation options immediately hides previously formatted output until rerun, preventing stale copies.

Processing is subject to synchronous bounds—a maximum input length of 200,000 UTF-16 code units, a token limit of 20,000 tokens including comments, a delimiter nesting depth of 128, and a serialized output limit of 2,000,000 UTF-16 code units measured before string joining—without background Web Worker isolation or execution deadline guarantees.

When using GraphQL in production environments, query payload size remains an important operational factor. In particular, when client applications transmit GraphQL operation documents to remote API servers over HTTP POST or GET requests, superfluous indentation spaces, line breaks, commas, and developmental comments expand request bodies and unnecessarily inflate network payloads.

This tool provides a dedicated Minify function to strip out comments and ignored whitespace, taking the exact opposite visual approach to the beautifier while strictly preserving GraphQL token semantics.

Crucially, minification does not rely on AST optimizations, schema-aware field shortening, or variable stripping: it systematically eliminates hash comments, commas, and unnecessary whitespace between tokens while preserving every raw string lexeme exactly as written.

Unlike older regular-expression minifiers that deleted comments before tokenizing string boundaries—thereby corrupting string values containing embedded # characters—the official lexer distinguishes comment tokens from string contents with absolute grammatical precision.

Quotes, block strings, and escape sequences remain intact. The actual transfer volume reduction realized in production depends on your transport protocol, HTTP compression (gzip/brotli), and caching strategy.

Minification also enforces strict input and token bounds, rejecting inputs exceeding 200,000 UTF-16 code units, 20,000 tokens including comments, or delimiter depths of 128.

If an input contains bracket mismatches, illegal tokens, unclosed quotes, or any syntactic failure, the minifier rejects the document entirely and refuses to emit partial output.

Additionally, editing the input text or changing configurations immediately hides previously generated results until the action button is re-triggered.

Protecting string literals and developmental comments requires rigorous adherence to the GraphQL specification rather than heuristic text replacement.

GraphQL source documents accommodate standard double-quoted strings ("..."), multiline triple-quoted block strings ("""..."""), escaped sequences, and comments beginning with a hash character (#).

Under obsolete regex-based formatting and minification pipelines, temporary placeholder tokens were swapped into source strings, risking accidental collisions whenever source payloads organically contained identical token strings.

Furthermore, naïve string trimming like trimEnd stripped significant trailing whitespace from block strings, and minifying before string isolation destroyed any literal # contained inside valid string values.

This tool formats and minifies documents by employing the official GraphQL 16.14.2 Lexer and Parser directly. It dispenses entirely with synthetic placeholder markers and regular expression substitution, extracting raw slices based on token source offsets so that string contents, escape sequences, and comments are never rewritten as synthetic tokens.

When beautifying or minifying documents, raw string and block-string lexemes—including interior line breaks, trailing spaces, internal double quotes, and escaped triple quotes—are preserved as originally sliced.

Hash comments are similarly recognized as independent lexical tokens: they are preserved in their contextual positions during formatting and cleanly omitted during minification without interfering with string contents.

If the document encounters mismatched delimiters, invalid quote sequences, unclosed blocks, or grammatical syntax errors, parsing halts, displaying a clear syntax error message while withholding partial output.

Processing operates within synchronous boundaries of 200,000 UTF-16 code units, 20,000 tokens, 128 nesting levels, and 2,000,000 UTF-16 output units, and memory persistence, file saving, and undo histories are not provided.

The most frequent careless mistakes when editing GraphQL operations or schemas involve unmatched opening and closing delimiters, mismatched braces, inverted bracket orders, or missing syntactic separators.

Rather than relying on superficial delimiter tallying across raw text that previously counted braces inside comments or strings, this tool evaluates the input through the official GraphQL 16.14.2 Lexer and Parser.

It verifies full grammatical syntax across queries, mutations, subscriptions, fragment declarations, and schema definition language (SDL), rigorously validating delimiter pairs, opening and closing balance, bracket ordering, and bracket depth up to a safe threshold of 128 nested levels.

If syntactic failure occurs—whether from misplaced brackets, trailing invalid tokens, or corrupted expressions—the operation produces an explicit syntax error, and no formatted or minified output is generated.

However, syntax parsing must not be confused with semantic query verification against an actual GraphQL schema. The formatting and minification workflow does not validate queries against any schema, nor does it perform field existence checks, directive validation, or remote network execution.

In contrast, the SDL Builder tab does perform schema validation across defined SDL types using official schema validation utilities, exempting only the missing Query root type requirement for partial schema building.

Once formatting or minification finishes successfully, you can copy the resulting document using the integrated copy button. The copy action utilizes an asynchronous shared clipboard workflow that handles promise rejections gracefully, alerts users if clipboard access is denied, and invalidates or hides the copied state whenever the source code is altered or the component unmounts.

Always verify pasted content in your project editor or test runner before committing, keeping in mind that client-side execution boundaries and browser environments do not provide absolute execution deadline or performance guarantees.

Another major feature is the Schema Builder, which enables developers to construct GraphQL Schema Definition Language (SDL) structures through an interactive, browser-based GUI without writing raw syntax from scratch.

The builder focuses exclusively on four fundamental GraphQL type constructs: Object types (type), Input Object types (input), Enumeration types (enum), and Union types (union).

When defining object or input structures, you can add fields, configure scalar types (String, Int, Float, Boolean, ID), or designate custom type references.

Detailed modifiers—such as non-null field requirements (!), list wrapping ([...]), and non-null list item requirements ([...!])—are configured through explicit checkboxes.

Enumerations allow case-sensitive value declarations, while unions aggregate valid object type definitions into polymorphic sets.

To maintain semantic integrity, the builder enforces strict validation constraints. Field names and type identifiers must comply with GraphQL ASCII identifier regex rules up to 128 characters, reject reserved double-underscore prefixes (__), and preserve exact case without arbitrary upper-case auto-conversion.

All type names across the builder must be case-sensitively unique, including uniqueness against built-in scalars. Enum values cannot be blank, duplicated, reserved with __, or named after boolean/null literals (true, false, null), and union members must be non-empty, unique object types.

Every referenced custom type must genuinely exist within the builder: input fields are restricted to input types, enums, or scalars and cannot reference output object types, while output types cannot reference input types.

Deleting a referenced type triggers a visible error banner and disables SDL copying rather than silently altering definitions. Furthermore, descriptions are rendered safely as standard GraphQL string values via JSON.stringify rather than vulnerable triple-quote injection.

The initial template provides a fully resolved Post definition alongside default types like User, avoiding orphan references.

The builder validates generated SDL using buildASTSchema and validateSchema, purposefully exempting only the missing Query root type requirement since the output is a modular type template rather than a server-ready schema.

Scale is capped at 100 types, 100 items per type, and 2,000 UTF-16 code units per description, while unfinished empty definitions immediately halt export until completed.

Formatting, minification, full syntax parsing, and SDL template construction are executed entirely within page memory by client-side JavaScript.

With the adoption of the official GraphQL 16.14.2 Lexer and Parser, the tool parses syntactic structures across queries, mutations, subscriptions, fragments, and SDL templates, completely avoiding historical placeholder bugs, raw comment collisions inside strings, and corrupted block string indentation.

Nonetheless, operational boundaries remain clearly defined: the tool performs official syntax parsing only and does not perform query schema validation, type checking, field resolution against remote schemas, or network API execution.

It does not validate interface implementations, custom directive definitions, or complete execution schemas beyond the provided SDL template capabilities.

The SDL builder rigorously validates definitions, rejecting reserved __ prefixes, duplicate names, invalid ASCII characters, empty types or items, and illegal cross-references between input and output types.

Generated schemas are validated against official schema AST builders, exempting solely the requirement for a root Query type so developers can model reusable type components.

However, this output is strictly an SDL type template and cannot be claimed as a complete, server-ready schema. Delimiter analysis is governed by parser tokenization rather than naive character counting, checking bracket order and nested delimiter depth up to 128 levels.

Across the application, synchronous performance boundaries enforce ceilings: 200,000 UTF-16 code units for GraphQL inputs, 20,000 tokens including comments, and 2,000,000 UTF-16 code units for generated output measured prior to final string assembly.

When preparing GraphQL operations or schema definitions for production, developers should treat client-side formatting as an intermediate authoring convenience rather than an authoritative test harness.

While the SDL Builder enforces structured consistency—capping definitions at 100 types, 100 items per type, 2,000 UTF-16 code units per type description, and 128 UTF-16 code units per identifier name, alongside the overall limits of 200,000 UTF-16 code units input, 20,000 tokens, 128 nesting levels, and 2,000,000 UTF-16 output units—it does not execute operations against a backend server, manage file persistence, or retain undo states across browser sessions.

Always integrate your formatted schemas and queries into formal automated testing pipelines, schema registries, and staging servers to validate business logic, type coverage, and field permissions prior to release.