T tomlkit·org
Inspect Formatter Validator Lint Stats Keys Query Convert TOML→JSON JSON→TOML TOML→YAML YAML→TOML INI→TOML TOML→INI .env→TOML TOML→.env TOML→TS TOML→CSV CSV→TOML TOML→XML TOML→.properties .properties→TOML Transform Sort keys Flatten Unflatten Redact Minify Generate Go struct Rust struct Python types JSON Schema Compare Diff Merge

TOML Stats

updated 20 August 2026

How big is this config, really? This counts the keys, tables, and arrays, measures how deep the nesting goes, breaks the values down by type, and reports the line-level facts — longest line, comment count, whether the file has CRLF endings.

— S., [email protected]
Open in Key ListerOpen in LinterOpen in Formatter
text report or JSON
In this page
  1. What this tool does
  2. When you'd reach for it
  3. How it works
  4. Options reference
  5. Example
  6. FAQ
  7. Related tools

What this tool does

It parses the document and reports two kinds of measurement. Structural counts come from the parsed tree: keys at every level, leaf values, tables, arrays of tables, plain arrays, maximum nesting depth, the longest key path, and the largest array with its location. Textual counts come from the raw input: bytes, lines, blank lines, comment lines, longest line, and whether CRLF endings or tab indentation are present.

The intent it closes: "is this file as complicated as it feels?" — the question you ask before a refactor, when deciding whether to split a config, or when a reviewer claims a file is unmanageable and you want a number instead of an opinion.

The type histogram is the part people find most useful in review: a config that is 90% strings usually wants an enum or a schema somewhere, and a surprise float in a list of integers is often a bug.

When you'd reach for it

  • Decide whether to split a config. Depth and top-level section counts tell you where the seams are.
  • Sanity-check a generated file. If a converter was supposed to produce 40 keys and the count says 12, something dropped.
  • Compare two environments. Run both and compare counts — a missing table stands out immediately.
  • Report on a migration. Before-and-after numbers make a config cleanup legible in a pull request.
  • Spot a runaway array. The largest-array line names the path, which is usually the thing making the file slow to read.

How it works

Two passes: one over the text, one over the parsed tree.

1. Measure the text

Before parsing, the raw input is measured: byte length (UTF-8, so multi-byte characters count for more than one), line count, how many of those are blank or start with #, the longest line, whether any CRLF pairs are present, and whether any line begins with a tab.

2. Walk the parsed tree

The document is parsed and traversed. Every key encountered increments the key count; leaves are classified by type; tables and arrays are counted separately, with arrays of tables tracked apart from plain arrays because they mean different things when you are reading a config. Depth is the deepest nesting level reached, and empty tables are counted as their own line since they are usually accidental.

3. Report

The text report is a two-column, aligned listing — readable and diff-friendly. The JSON format has the same numbers in a nested object (text, counts, topLevelSections), which is the shape to use if you want to assert on a count in CI.

Options reference

Format

Text report is aligned for reading and pasting into a pull request. JSON gives you the same figures programmatically — useful for a CI check like "the config must not exceed depth 4" or "top-level sections must not exceed 12".

Example

Input (the sample config):

[service]
name = "checkout"
replicas = 3

[service.env]
LOG_LEVEL = "info"

[[service.ports]]
port = 8080

Output (trimmed):

Bytes              98
Lines              9 (2 blank, 0 comment)
Keys (all levels)  6
Leaf values        4
Tables             3
Arrays of tables   1
Max nesting depth  4
Longest key path   service.ports[0].port

Note that Keys (all levels) counts table keys as well as value keys — service and service.env are keys too. Leaf values is the count of actual settings, which is usually the number people mean when they ask how big a config is.

FAQ

What counts as a key?

Every key at every level, including the ones whose value is a table. Leaf values is the narrower figure — only keys holding a scalar or an array of scalars — and it is the better answer to "how many settings does this file have?"

How is depth measured?

The root table is depth 0, a key inside it is depth 1, and each nested table or array-of-tables entry adds one. A key inside [a.b.c] therefore sits at depth 4.

Why does the byte count differ from my editor?

Bytes are counted as UTF-8, so an accented character or an emoji counts for more than one. Editors often show characters instead. Line endings also count: a CRLF file has one extra byte per line.

Can I use this in CI?

Yes, by asserting on the JSON output — but you would run that assertion with a real TOML library in your CI language. This page is the interactive version of the same numbers.

Are comments counted?

Whole-line comments are, from the raw text. Trailing comments after a value are not counted separately, and no comment content ever reaches the parsed tree.