🔧 TL3 Tools

Two Text Formats, One Data Model

YAML and JSON both describe the same kind of nested structure — objects, arrays, strings, numbers, booleans, and nulls — but they look very different on the page. JSON wraps everything in braces and quotes, while YAML uses indentation and dashes to express the same shape with less visual noise. This page translates between the two, accepting hand-written YAML or pasted JSON and producing the counterpart format with consistent indentation. All of the parsing and generation runs locally in the browser, so configuration files and API payloads you paste in are never sent to a server.

Worked Example: One Service, Both Faces

Consider a small deployment configuration for a web service. In YAML the same data reads naturally, with two-space indentation marking the nesting:

name: tl3-api
version: 1.4.0
region: eu-west-1
replicas: 3
features:
  - health
  - metrics
logging:
  level: info
  format: json

Converted to JSON, the identical structure becomes a compact block of braces and quotes:

{
  "name": "tl3-api",
  "version": "1.4.0",
  "region": "eu-west-1",
  "replicas": 3,
  "features": ["health", "metrics"],
  "logging": {"level": "info", "format": "json"}
}

Notice that the array of features and the nested logging object survive the round trip unchanged, which is the whole point of a faithful conversion.

Indentation Is the Grammar of YAML

In JSON, the brackets define where one structure ends and another begins. In YAML, that job falls to indentation, so a stray extra space can silently change which key a value belongs to. The parser here is strict about inconsistent indentation and reports the offending line instead of guessing. When converting from JSON to YAML, the tool regenerates indentation from the structure, so the output is always consistent even if your source JSON was minified onto a single line.

Where Each Format Earns Its Keep

• Configuration files — YAML is easier for humans to review and edit, which is why CI pipelines and container orchestrators favor it.
• Machine-to-machine exchange — JSON parses natively in every programming language and in browser fetch calls.
• Documentation and samples — YAML examples take less horizontal space and read more like a spec sheet.
• Log aggregation — JSON lines are the de facto standard for structured logs that tools must parse at scale.

What the Converter Does Not Guess At

Anchors, aliases, multi-document streams, and custom tags are advanced YAML features that fall outside the supported set, and input using them produces a clear error rather than a silently wrong result. YAML comments beginning with a hash are stripped on the way to JSON, because JSON has no comment syntax at all. Booleans and nulls are recognized in their standard spellings, so true, false, and null convert to their JSON equivalents rather than to quoted strings.

Working With the Output Panel

The converted result appears in the lower pane as soon as you click the convert button, with the indentation you selected, either two or four spaces. A copy button places the entire output on your clipboard in one action, which is handy when the file is about to be pasted into a deployment tool. Because nothing is uploaded, you can freely convert internal configuration that would never be allowed past a network boundary.

Quoting and Type Inference

YAML guesses the type of every value, so a bare 1 becomes a number while the quoted string "1" stays text. The same distinction exists in JSON, where numbers are written without quotes and strings always carry them. Values like version 1.4.0 or a leading-zero code are the usual victims: wrap them in quotes in the YAML source, and the JSON output will keep them as strings instead of mangling them into numbers.

Large Files and Local Performance

Because parsing and generation run inside the tab, documents in the low hundreds of kilobytes convert essentially instantly, and nothing is transmitted while they do. A multi-megabyte file may take a moment because the entire tree is built in memory before the output is rendered. For files that large, keeping the browser tab focused and waiting for the result is all the interaction the converter needs.

Flow Style, Block Style, and Duplicate Keys

YAML authors choose between flow style, which packs a map onto a single line inside braces, and block style, which spreads the same structure over indented lines; both are valid YAML and describe the same data. Duplicate keys are a classic silent bug, because two lines assigning the same name leave the second value in charge, so searching the file before converting is the safest habit. Tab characters are invalid in YAML indentation, which makes files produced by tab-indenting tools fail loudly; switching the editor to spaces fixes the error in one setting. As a document grows past a few hundred lines, sorting keys alphabetically makes later merge conflicts easier to resolve, because reviewers can see exactly which entries changed.