Lightning YAML
Spec-compliant YAML,
approaching JSON speed.
A pure-JS YAML 1.2 parser and stringifier that's out to give native JSON.parse a run for its money — spec compliance first, then speed and memory within reach of it. On ~100 KB of block-YAML config, in Chrome's engine: 2.7× faster than js-yaml (up to 11× depending on engine and file size) and 24× faster than yaml — and about 2.9× JSON.parse's parse time on the equivalent JSON. Zero dependencies, 12.0 KB min+gzip.
pnpm add lightning-yamlTime to parse() block-YAML config, relative to Lightning YAML (always 1.0×) — the shape most real-world YAML takes. Scaled to the runner-up; yaml runs off-scale (↗). JSON.parse sits out: it can’t read block YAML. Click a ratio for per-engine results.
- node 24.18.0 (x64-linux)3.9×
- chromium 141.0.7390.37 (x64-linux)2.7×
- webkit 26.0 (x64-linux)3.7×
- node 24.18.0 (x64-linux)48×
- chromium 141.0.7390.37 (x64-linux)24×
- webkit 26.0 (x64-linux)35×
- node 24.18.0 (x64-linux)3.5×
- chromium 141.0.7390.37 (x64-linux)2.7×
- webkit 26.0 (x64-linux)4.0×
- node 24.18.0 (x64-linux)50×
- chromium 141.0.7390.37 (x64-linux)24×
- webkit 26.0 (x64-linux)34×
- node 24.18.0 (x64-linux)4.0×
- chromium 141.0.7390.37 (x64-linux)3.1×
- webkit 26.0 (x64-linux)11×
- node 24.18.0 (x64-linux)46×
- chromium 141.0.7390.37 (x64-linux)24×
- webkit 26.0 (x64-linux)43×
Time to stringify() the same parsed config, relative to Lightning YAML (always 1.0×) — JSON.stringify included as a baseline on the same value. Click a ratio for per-engine results.
- node 24.18.0 (x64-linux)0.3×
- chromium 141.0.7390.37 (x64-linux)0.3×
- webkit 26.0 (x64-linux)0.1×
- node 24.18.0 (x64-linux)8.8×
- chromium 141.0.7390.37 (x64-linux)9.0×
- webkit 26.0 (x64-linux)9.4×
- node 24.18.0 (x64-linux)25×
- chromium 141.0.7390.37 (x64-linux)21×
- webkit 26.0 (x64-linux)26×
- node 24.18.0 (x64-linux)0.3×
- chromium 141.0.7390.37 (x64-linux)0.3×
- webkit 26.0 (x64-linux)0.2×
- node 24.18.0 (x64-linux)8.6×
- chromium 141.0.7390.37 (x64-linux)8.5×
- webkit 26.0 (x64-linux)9.0×
- node 24.18.0 (x64-linux)24×
- chromium 141.0.7390.37 (x64-linux)22×
- webkit 26.0 (x64-linux)23×
- node 24.18.0 (x64-linux)0.3×
- chromium 141.0.7390.37 (x64-linux)0.3×
- webkit 26.0 (x64-linux)0.1×
- node 24.18.0 (x64-linux)8.5×
- chromium 141.0.7390.37 (x64-linux)7.6×
- webkit 26.0 (x64-linux)6.2×
- node 24.18.0 (x64-linux)19×
- chromium 141.0.7390.37 (x64-linux)19×
- webkit 26.0 (x64-linux)15×
Peak memory of the Node process while parsing, relative to Lightning YAML (always 1.0×) — lower is better. Click a ratio for every environment’s own number, browser engines included — each measures what its engine exposes (Chrome: memory the parsed result retains; WebKit: its page process’s peak), so they read differently on purpose.
- node 24.18.0 (x64-linux) · Node · peak memory of the whole process1.0×
- chromium 141.0.7390.37 (x64-linux) · Chrome's engine · memory retained by the parsed result1.0×
- webkit 26.0 (x64-linux) · Safari's engine (WebKit) · peak memory of the page process1.1×
- node 24.18.0 (x64-linux) · Node · peak memory of the whole process1.0×
- chromium 141.0.7390.37 (x64-linux) · Chrome's engine · memory retained by the parsed result1.7×
- webkit 26.0 (x64-linux) · Safari's engine (WebKit) · peak memory of the page process7.4×
- node 24.18.0 (x64-linux) · Node · peak memory of the whole process1.3×
- chromium 141.0.7390.37 (x64-linux) · Chrome's engine · memory retained by the parsed result1.0×
- webkit 26.0 (x64-linux) · Safari's engine (WebKit) · peak memory of the page process2.2×
- node 24.18.0 (x64-linux) · Node · peak memory of the whole process3.5×
- chromium 141.0.7390.37 (x64-linux) · Chrome's engine · memory retained by the parsed result1.0×
- webkit 26.0 (x64-linux) · Safari's engine (WebKit) · peak memory of the page process3.0×
- node 24.18.0 (x64-linux) · Node · peak memory of the whole process2.8×
- chromium 141.0.7390.37 (x64-linux) · Chrome's engine · memory retained by the parsed result1.0×
- webkit 26.0 (x64-linux) · Safari's engine (WebKit) · peak memory of the page process2.8×
- node 24.18.0 (x64-linux) · Node · peak memory of the whole process4.7×
- chromium 141.0.7390.37 (x64-linux) · Chrome's engine · memory retained by the parsed result1.0×
- webkit 26.0 (x64-linux) · Safari's engine (WebKit) · peak memory of the page process4.2×
Browser bundle (parse + stringify), min + gzip — smallest across every bundler measured. Deterministic and environment-free, so this tab stays absolute.
lightning-yaml 0.1.1 · yaml 2.9.0 · js-yaml 5.2.1Full benchmarks →
Help us break it
Paste any YAML or JSON and hit Run — all three parsers race on your input in your browser, then dump it back and race again. If you find a case wherelightning-yaml is slower, or disagrees with the others, you've found something we want to fix — the numbers are one click from a GitHub issue.
What we optimise for
Spec-correct
97.6% of the YAML Test Suite — more of the spec than js-yaml(94.9%) or yaml (97.1%).
JSON-class speed
Parses at ~0.5× JSON.parse; 4–39× the JS competition on block YAML.
Lean memory
Peak RSS ≈1.3× JSON.parse — well under js-yaml /yaml.
Small bundle
≈12 kB min+gzip · tree-shakeable · zero deps.
- Anchors, aliases, !!binary & multi-doc streams
- parse · parseAll · stringify
- js-yaml / yaml drop-in shims
- TypeScript-first types
- Zero dependencies
Drop-in is API-level today. Imports and call signatures matchjs-yaml and yaml, so existing code runs — but an option argument we don't yet honour (schema, sortKeys, indent, …)throws rather than silently changing your output. Useful for migrating now; not yet a 1:1 behavioural match.