What validation errors can the tool detect?

The formatter detects indentation errors, invalid YAML syntax, unclosed quotes, malformed keys and values, and incorrect nesting. Error messages indicate the line and type of issue.

Will the formatter convert my YAML to a different format?

No, the formatter only fixes indentation and spacing while preserving your YAML structure and content. It doesn't change the data or convert to other formats.

Does YAML Formatter & Validator work with large files?

Yes, since it runs in your browser, it can handle reasonably large inputs. Performance depends on your device's capabilities.

क्या मैं इसे मोबाइल डिवाइस पर उपयोग कर सकता हूँ?

Yes, this tool works on any device with a modern browser including phones and tablets.

Are my YAML files uploaded to a server?

No. The formatter runs 100% in your browser with js-yaml, pasted content never leaves your device. Safe for Kubernetes manifests, CI configs, or other YAML that may contain secrets or internal hostnames.

YAML फॉर्मेटर

YAML को फ़ॉर्मेट और सत्यापित करने के लिए पेस्ट करें। त्रुटियाँ तुरंत देखें, इंडेंटेशन ठीक करें और JSON में कनवर्ट करें।

स्थानीय रूप से प्रसंस्कृत · कुछ भी सर्वर पर नहीं भेजा जाता

YAML इनपुट

फ़ॉर्मेट किया गया आउटपुट

सत्यापित करने के लिए YAML पेस्ट करें

YAML क्या है?

YAML (YAML Ain't Markup Language) एक मानव-पठनीय डेटा सीरियलाइज़ेशन प्रारूप है, जिसका उपयोग कॉन्फ़िगरेशन फ़ाइलों के लिए होता है।

अक्सर पूछे जाने वाले प्रश्न

सत्यापक कौन सी त्रुटियों का पता लगाता है?

इंडेंटेशन त्रुटियाँ, लापता कोलन, डुप्लिकेट कुंजियाँ, अमान्य वर्ण, अनबंद स्ट्रिंग्स, ग़लत नेस्टिंग और अन्य समस्याएँ।

क्या मैं YAML को JSON में रूपांतरित कर सकता हूँ?

हाँ! अपने YAML को अच्छी तरह फ़ॉर्मेट किए गए JSON में रूपांतरित करने के लिए "→ JSON" बटन पर क्लिक करें। उल्टे रूपांतरण के लिए, हमारे JSON से YAML टूल का उपयोग करें।

A Quick Tour of YAML

YAML 1.0 was published in 2001 by Clark Evans, Ingy döt Net, and Oren Ben-Kiki; YAML 1.1 followed in 2005, and the current version is YAML 1.2.2, which fixed several historical gotchas (notably the "Norway problem", see below) and was designed to be a strict superset of JSON. The official spec lives at yaml.org/spec/1.2.2. This formatter uses the open-source js-yaml library, which parses against the YAML 1.2 schema by default, so most of the legacy 1.1 quirks don't apply to text formatted here, but they do apply to most server-side YAML tooling you'll send the output to.

Where YAML Actually Lives

YAML has won as the configuration format for cloud-native infrastructure. The places you'll meet it most:

Kubernetes manifests: every Pod, Deployment, Service, ConfigMap, Ingress is a YAML document. Helm charts are YAML wrapped around Go templating.
CI/CD workflows: GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines, Drone, Jenkinsfile (declarative pipelines), Argo Workflows.
Docker Compose: multi-container application definitions.
Ansible playbooks: the configuration-management standard.
Static-site generators: Jekyll's _config.yml, Hugo's config.yaml, Eleventy's various config files.
OpenAPI specifications: REST API contracts, often authored as YAML and converted to JSON only when needed.
Application config: Spring Boot's application.yml, Rails' database configs, many Python and Go services.

The Whitespace Trap (Spaces Only)

YAML uses indentation to denote structure, and the spec is explicit that tabs are not allowed for indentation. Only spaces. This is the single most common source of bugs in handwritten YAML, especially because many editors silently mix tabs and spaces depending on their settings. The error message you'll get from a strict parser is along the lines of "found character '\t' that cannot start any token", translation: "you used a tab somewhere." The fix is universal: enable "show whitespace" in your editor and convert every tab to two or four spaces.

Indent size is convention rather than spec. 2 spaces is the de facto standard for Kubernetes manifests, GitHub Actions, and most YAML you'll read on the modern web. 4 spaces is more common in Ansible. The rule that matters: be consistent within a single file. Mixing 2 and 4 spaces between sibling keys is what trips parsers, not which size you pick.

The Norway Problem (and Why You Should Quote Ambiguous Strings)

YAML 1.1 (still the default in PyYAML, snakeyaml, and many other server-side parsers) interprets a long list of unquoted boolean spellings as actual booleans: true, True, TRUE, false, False, FALSE, yes, Yes, YES, no, No, NO, y, n, on, off. The famous trap: the ISO country code for Norway is NO. A YAML config that lists countries as unquoted strings silently parses Norway as the boolean false, and downstream code reading countries[0] == 'NO' fails confusingly.

YAML 1.2 (and js-yaml's default schema) restricted booleans to just true / false, which fixes the Norway problem at the parser level. But many real-world tools still default to the YAML 1.1 schema for backward compatibility. The defensive habit: quote any string that looks like it could be a boolean, number, date, or version. country: "NO", postal_code: "01234", version: "1.10", time: "10:30". Quotes are the universal disambiguator.

Other Type-Coercion Gotchas

Sexagesimal numbers (YAML 1.1). An unquoted 10:30 parses as the integer 630 (ten times sixty plus thirty). Anything that looks like a time-of-day needs quotes.
Octal numbers. An unquoted 012 parses as the integer 10 in YAML 1.1 (octal interpretation of leading-zero numbers). US zip codes, employee IDs, postal codes that begin with zero must be quoted: zip: "01234".
Version-number floats. An unquoted 1.10 parses as the float 1.1. Always quote semver strings: version: "1.10".
Scientific notation. 1e5 parses as the number 100000. If you genuinely meant the string "1e5" (a product code, an internal ID), quote it.
Very large integers. JavaScript-based YAML parsers (including js-yaml) can lose precision on integers above 2⁵³−1. For 64-bit IDs, transmit as strings.

Block Style vs Flow Style

YAML supports two notations for the same data:

# Block style (the standard, indentation-based)
person:
  name: Alice
  tags:
    - admin
    - billing

# Flow style (JSON-like inline)
person: { name: Alice, tags: [admin, billing] }

Block style is what you'll see in 99% of hand-written YAML, it's what makes the format readable. Flow style is a useful escape hatch for short single-line values or for programmatically generating YAML where you'd rather not track indentation. The formatter normalises to block style for output (the more readable form) regardless of which style your input used.

Anchors and Aliases (the DRY Trick)

YAML's reusability feature: define a value once with the &name anchor, reference it elsewhere with the *name alias. Convenient for long config files where the same block of values appears multiple times.

defaults: &defaults
  region: us-east-1
  log_level: info

production:
  <<: *defaults
  log_level: warn   # override

staging:
  <<: *defaults

A few caveats: not every YAML processor supports anchors and aliases (notably some older Kubernetes manifest tools and certain Helm contexts). The <<: "merge key" syntax shown above is a YAML 1.1 extension and is officially deprecated in 1.2, js-yaml supports it, but pure 1.2 parsers may not.

Multi-Document Files

A single YAML file can contain multiple documents, separated by ---. Common in Kubernetes, one file with a Deployment, a Service, and a ConfigMap, separated by ---, applied with one kubectl apply -f:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
---
apiVersion: v1
kind: Service
metadata:
  name: app-svc

YAML vs JSON vs TOML

JSON: machine-friendly, no comments allowed, bracketed. Universal API payload format.
YAML: human-friendly, comments allowed, indentation-based, error-prone for humans. Universal config format for cloud-native tooling.
TOML: human-friendly, comments allowed, INI-style, far less error-prone than YAML for flat configuration. Cargo (Rust), Hugo, Black (Python), Poetry, modern Pip, all use TOML.

If you have a choice for new config: TOML for flat configuration, YAML if you need deep nesting and the ecosystem has standardised on it (Kubernetes, Ansible), JSON if a machine writes it. YAML is the right format when humans need to read deeply nested config and write meaningful comments inline.

Privacy

YAML configs frequently contain secrets that shouldn't go through someone else's server: Kubernetes Secret base64 blobs, database passwords in application.yml, API keys in CI workflows, internal hostnames in deployment configs. The formatter runs entirely in your browser via the open-source js-yaml library, pasted content is parsed and re-emitted locally, with no fetch / no upload / no logging. Closing the tab wipes everything.

Common Mistakes

Mixing tabs and spaces in indentation. The most common error. Tabs are forbidden by the spec; some editors insert them silently. Show whitespace in your editor.
Inconsistent indentation between siblings. Sibling keys must be aligned at the same column. Mixed 2/4-space indentation breaks the parse.
Unquoted values that look like booleans, numbers, dates, or times. NO, 012, 1.10, 10:30, yes: quote them.
Missing space after the colon. key: value works; key:value is invalid (parsed as a single string).
Trailing whitespace. Some parsers treat trailing spaces as significant; some don't. The cross-tool-safe habit is to strip trailing whitespace.
Multi-line strings without the right block scalar. Long strings need | (literal, preserves newlines) or > (folded, joins lines). Plain unquoted multi-line text rarely behaves the way you expect.
Anchors / aliases assumed everywhere. Helm and some Kubernetes contexts don't fully support &/*. Test in your real pipeline before depending on them.
Encoding mismatches. YAML files should be UTF-8. A Windows editor saving as UTF-16 with BOM produces files that some parsers can't read.