JSON ⇄ YAML ⇄ TypeScript

Three formats, one shape

JSON, YAML, and a TypeScript interface are three views of the same structure. JSON is what APIs return and most tooling reads. YAML is what humans are asked to write for CI pipelines, Kubernetes manifests, Docker Compose files, and app config, because it drops the braces and quotes. A TypeScript interface is the contract your code needs so that config.database.port is a number and not any.

Paste either JSON or YAML on the left. The tool detects which one it is, then lets you switch the right pane between pretty-printed JSON, YAML, and TypeScript. Everything runs in your browser, so pasting a config that contains API keys or connection strings is safe. Copy the active output pane at any point, or download it as a .json, .yaml, or .ts file.

JSON to YAML

{
  "service": "api",
  "replicas": 3,
  "env": {
    "NODE_ENV": "production",
    "PORT": 3000
  },
  "tags": ["web", "public"]
}

service: api
replicas: 3
env:
  NODE_ENV: production
  PORT: 3000
tags:
  - web
  - public

Nesting becomes indentation and arrays become dashed lists. Strings are left unquoted unless YAML would misread them, which is the part people get wrong by hand: a version like 1.10 would be parsed as the number 1.1, no and yes are booleans in older YAML parsers, and a value starting with * or & is an alias. The converter quotes those cases for you. Use the indent option to match the two-space or four-space style of the file you are pasting into.

YAML to JSON

Going the other way is where YAML surprises show up. Comments are dropped because JSON has no syntax for them. Anchors and aliases are expanded into the repeated values they stand for. Multi-line strings written with | or > become single JSON strings with \n escapes. If the YAML has a tab character where indentation is expected, or a key with no value at the wrong level, the tool reports the parse error with a line number instead of guessing.

A common use is checking what a CI system will actually see: paste the workflow YAML, read the JSON, and the ambiguous unquoted values are suddenly obvious.

Generating TypeScript interfaces

{
  "id": 42,
  "user_name": "ada",
  "profile": {
    "bio": null,
    "links": ["https://a.dev"]
  }
}

export interface Profile {
  bio: null;
  links: string[];
}

export interface Root {
  id: number;
  user_name: string;
  profile: Profile;
}

Every nested object becomes its own named interface, taken from the key that holds it, so the output drops straight into a .ts file. Arrays are typed from their elements, and an array of objects produces one interface for the element shape.

The options and when to use them

• Optional fields marks every property with ?. Use it for API responses where fields are sometimes absent; leave it off for config files that are always complete.
• camelCase keys renames user_name to userName. Only turn it on if your code also renames the data, otherwise the type will not match the runtime object.
• readonly properties adds readonly to each field, which stops accidental mutation of loaded config.

Remember the interface is inferred from one sample. A field that is null in your sample is typed as null; if it can also be a string, widen it by hand to string | null.

Where it fits in a working day

• Typing an API response: call the endpoint once, paste the JSON, copy the interfaces, then tighten the few fields that vary.
• Converting a docker-compose.yml or Helm values file to JSON to feed a script that only reads JSON.
• Reformatting minified JSON from a log line into something readable with consistent indentation.
• Producing a YAML example for documentation from the JSON your service actually emits, so the docs cannot drift from reality.

If the payload is large and headed for a language model as context, YAML is usually the more compact choice; check the difference with the token counter.