YAML 1.2 by default · Local worker · Reviewable output

YAML Formatter & Pretty Printer Online

Turn compact or inconsistently indented YAML into a readable serialization. Choose the schema deliberately, keep multi-document streams together, and inspect every presentation change before using the result.

Format YAML nowFree · No upload · 200,000-code-unit limit
service.yaml
service:
  name: liveparse
  ports:
    - 4173
  private: true

Consistent serializationMeaning still needs application tests

Parse, serialize, then review

Pretty-print YAML in your browser

The formatter uses yaml version 2.9.0 in a local worker. YAML 1.2 Core Schema is the default; YAML 1.1 is an explicit compatibility choice. Multi-document streams, anchors, aliases, and block scalars are supported, while merge-key expansion remains disabled.

Loading the private YAML formatter…

Enable JavaScript to format YAML locally. The workflow, version boundary, and review guidance below remain available without it.

A deliberate formatting workflow

How to format YAML online without hiding changes

Pretty printing is a source transformation, not a promise that the original text will be reproduced token for token.

  1. 1

    Paste YAML or open a local file

    Use one document or a stream separated by ---. Input is capped at 200,000 UTF-16 code units so an unexpectedly large configuration cannot monopolize the tab.

  2. 2

    Choose schema and indentation

    Keep YAML 1.2 Core unless the consuming system specifically requires YAML 1.1 behavior. Values such as yes, no, on, and off can resolve differently between those choices.

  3. 3

    Compare and test the output

    The formatter parses and reserializes. Review a source diff, then run the target application's parser and tests before committing a Kubernetes manifest, CI workflow, Compose file, or deployment configuration.

Readable is not byte-identical

What YAML formatting can change

YAML has both a data model and many presentation choices. The same scalar can be written plainly, quoted, or as a block scalar. Collections can use block or flow style. Blank lines, indentation, comments, directives, and document markers also shape the source a person reviews. A parser-backed formatter constructs documents and serializes them again, so it does not promise to retain every original spelling or position.

Expect indentation, whitespace, quote choice, flow-versus-block style, scalar presentation, equivalent numeric spelling, document markers, and comment placement to change when the serializer decides another representation is appropriate. LiveParse stops formatting before runtime rounding, underflow, overflow, or non-zero sub-millisecond timestamp truncation would change a value. Anchors and aliases remain YAML concepts, but their placement can be presented differently. Formatting does not expand the optional merge key: a << entry is not silently turned into copied mapping pairs.

A valid-looking output can still be wrong for a particular tool. Kubernetes, Docker Compose, GitHub Actions, Ansible, and application configuration loaders apply schemas and conventions beyond YAML syntax. Use the YAML Validator for a focused syntax, alias-order, and duplicate-scalar-key result, then use the authoritative application validator for domain rules.

Default schema
YAML 1.2 Core Schema, selected explicitly by the page.
Compatibility
YAML 1.1 is available only when an older consumer requires it.
Merge keys
Expansion is disabled; formatting does not manufacture merged pairs.
Output meaning
Syntax can be parsed, but application schemas and business rules remain separate.

Modern YAML document features

Multi-document streams, block scalars, anchors, and aliases

Multiple documents

A stream can contain several documents separated by ---. The formatter keeps them as a stream instead of pretending every input is one mapping.

Block scalars

Literal | and folded > scalars have chomping and indentation rules. Review rendered scalar values as well as the changed source presentation.

Anchors and aliases

An anchor names a node and an alias refers to it. They are not simple text substitution, and downstream loaders can impose their own alias limits.

Schema-sensitive scalars

A plain scalar's resolved type depends on the selected schema. Do not switch between YAML 1.2 and 1.1 merely to make an unexpected value appear acceptable.

Configuration stays in this tab

Private YAML formatting with bounded work

Configuration files can contain internal hostnames, account names, image registries, environment identifiers, or secrets. LiveParse sends the YAML operation to a Web Worker created by the page; it does not post the document to a formatting service. Copying, downloading, browser extensions, clipboard history, screen sharing, and other device software remain outside that boundary.

The page accepts at most 200,000 UTF-16 code units and performs parsing away from the interface thread. Those limits protect an interactive browser tool; they do not certify an arbitrary YAML document as safe for every downstream loader. Alias handling, custom tags, executable constructors, and schema choices must also be reviewed wherever the file is ultimately consumed.

Need another representation?

Inspect nodes without expanding aliases in the tree viewer, or convert supported YAML values to strict JSON with explicit loss warnings.

Open the YAML Viewer →
Convert YAML to JSON →

Formatting boundaries

YAML formatter FAQ

Does the YAML formatter preserve the original presentation?

No. It parses and reserializes the document, so indentation, quoting, scalar style, flow style, spacing, document markers, and comment placement can change. Review a diff and test the consumer before replacing source.

Which YAML versions does the formatter support?

It uses yaml version 2.9.0 with YAML 1.2 Core Schema by default and offers YAML 1.1 as an explicit compatibility option. Merge-key expansion remains disabled.

Does the YAML formatter upload configuration files?

No. Parsing and formatting run in a local Web Worker. Input is limited to 200,000 UTF-16 code units and is not sent to a formatting API.

Does formatted YAML pass Kubernetes or Docker Compose validation?

Not necessarily. Formatting proves neither a Kubernetes resource schema nor a Compose specification. Run the platform's authoritative validation after reviewing the formatted source.