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.5× faster than js-yaml (up to 4.5× depending on engine and file size) and 32× faster than yaml — and about 2.9× JSON.parse's parse time on the equivalent JSON. Zero dependencies, 12.1 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.21.0 (x64-linux)3.3×
- chromium 141.0.7390.37 (x64-linux)2.7×
- webkit 26.0 (x64-linux)3.7×
- node 24.21.0 (x64-linux)43×
- chromium 141.0.7390.37 (x64-linux)24×
- webkit 26.0 (x64-linux)36×
- node 24.21.0 (x64-linux)3.3×
- chromium 141.0.7390.37 (x64-linux)2.5×
- webkit 26.0 (x64-linux)4.2×
- node 24.21.0 (x64-linux)52×
- chromium 141.0.7390.37 (x64-linux)32×
- webkit 26.0 (x64-linux)44×
- node 24.21.0 (x64-linux)4.0×
- chromium 141.0.7390.37 (x64-linux)3.0×
- webkit 26.0 (x64-linux)4.5×
- node 24.21.0 (x64-linux)54×
- chromium 141.0.7390.37 (x64-linux)31×
- webkit 26.0 (x64-linux)58×
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.21.0 (x64-linux)0.3×
- chromium 141.0.7390.37 (x64-linux)0.2×
- webkit 26.0 (x64-linux)0.1×
- node 24.21.0 (x64-linux)9.5×
- chromium 141.0.7390.37 (x64-linux)8.4×
- webkit 26.0 (x64-linux)51×
- node 24.21.0 (x64-linux)24×
- chromium 141.0.7390.37 (x64-linux)21×
- webkit 26.0 (x64-linux)24×
- node 24.21.0 (x64-linux)0.3×
- chromium 141.0.7390.37 (x64-linux)0.3×
- webkit 26.0 (x64-linux)0.1×
- node 24.21.0 (x64-linux)11×
- chromium 141.0.7390.37 (x64-linux)9.9×
- webkit 26.0 (x64-linux)54×
- node 24.21.0 (x64-linux)24×
- chromium 141.0.7390.37 (x64-linux)23×
- webkit 26.0 (x64-linux)26×
- node 24.21.0 (x64-linux)0.3×
- chromium 141.0.7390.37 (x64-linux)0.3×
- webkit 26.0 (x64-linux)0.1×
- node 24.21.0 (x64-linux)8.7×
- chromium 141.0.7390.37 (x64-linux)7.9×
- webkit 26.0 (x64-linux)24×
- node 24.21.0 (x64-linux)19×
- chromium 141.0.7390.37 (x64-linux)17×
- webkit 26.0 (x64-linux)12×
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.21.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.2×
- webkit 26.0 (x64-linux) · Safari's engine (WebKit) · peak memory of the page process1.3×
- node 24.21.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.6×
- webkit 26.0 (x64-linux) · Safari's engine (WebKit) · peak memory of the page process10×
- node 24.21.0 (x64-linux) · Node · peak memory of the whole process1.1×
- 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.21.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.1×
- node 24.21.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.9×
- node 24.21.0 (x64-linux) · Node · peak memory of the whole process4.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 process3.7×
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.4.3Full 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
98.4% (367/373) on the YAML Test Suite. See the measured comparison. Generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1
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 compatibility shims
- TypeScript-first types
- Zero dependencies
Compatibility is partial today. The shims expose selected functions, not the full exports or every call signature of js-yaml andyaml. Unsupported options throw rather than being silently ignored; see the module references for current support.