How to convert JSON to YAML without losing types

Short answer

Converting JSON to YAML without losing types means preserving each value’s meaning, not just replacing braces with indentation. A boolean must remain a boolean, null must not become text, and a string like "1.0" must remain a string even though it looks like a number.

The Tools in a Tab JSON to YAML converter applies these rules locally: it validates the input, preserves numeric tokens and quotes strings that could be reinterpreted. This guide explains what it does and what you should check next.

Complete example: same data, different representation

We start from a configuration with objects, a list and several types of scalars:

{
  "service": {
    "port": 8080,
    "active": true,
    "version": "1.0",
    "date": "2026-08-06",
    "tags": ["production", "private"],
    "limit": null
  }
}

The conversion produces:

service:
  port: 8080
  active: true
  version: "1.0"
  date: "2026-08-06"
  tags:
    - production
    - private
  limit: null

In this block-style output, indentation, colons, and dashes replace braces and commas. Types do not change: 8080 remains a number, true a boolean, null a null value, and the quoted values remain strings.

Type equivalence between JSON and YAML

YAML can represent more constructs than JSON, but a conversion from JSON only needs this subset. There are no comments, anchors, aliases or tags in the input that can be transferred to the result.

The converter preserves the order in which the properties appear so that the file is easy to compare. That order is a presentation decision: it should not carry meaning in a YAML mapping. If order is part of the data, represent it using an array.

Safe conversion procedure

1. Confirm that the input is strict JSON. Comments, single-quoted strings, and trailing commas are not part of the format.
2. Convert the entire document without making global substitutions.
3. Check for strings that look like booleans, null values, numbers, or dates.
4. Check large numbers and decimals with the capabilities of the program that will read the YAML.
5. Validate the result in the target application. Correct YAML syntax does not guarantee compliance with its configuration schema.

If the first step fails, use the JSON validator to locate the error before converting. Formatting the input is optional: the JSON formatter can make it more readable without changing its types.

Quote strings that might look like another type

Unquoted scalars can resolve as numbers, booleans, or null. Some applications also use their own schemas or rules for dates and other values. Quoting an ambiguous string prevents YAML scalar resolution from changing its type.

{
  "enabled": "true",
  "empty": "null",
  "code": "0042",
  "answer": "yes"
}

The result preserves all four values as text:

enabled: "true"
empty: "null"
code: "0042"
answer: "yes"

Do not remove those quotes just to shorten the file. "true" and true do not mean the same thing; neither do "null" and null. A code like "0042" is text when the leading zero is part of the identifier.

YAML 1.2 Core considers yes, no, on and off strings, unlike the older YAML 1.1 rules. The converter quotes them for compatibility with older readers and different configurations.

Large numbers require two checks

The first check occurs during the conversion. Tools in a Tab reads the numeric token directly from JSON, so it doesn’t round the integer or rewrite the exponent:

{
  "id": 9007199254740993123456789,
  "threshold": 1.25e+3,
  "zero": -0
}

id: 9007199254740993123456789
threshold: 1.25e+3
zero: -0

The second check belongs to the YAML consumer. YAML’s integer model allows arbitrary size, but a library or application can use native types with a smaller range. Decimal values also depend on the available precision. If digits represent an identifier rather than a quantity, a string usually expresses that intention better.

Preserving the type does not mean preserving the exact notation forever. A reader can normalize 1.25e+3 to another equivalent notation or display -0 as 0 without having converted the value to text.

Empty arrays, objects and collections

Arrays maintain the order of their elements. Nested objects become maps, and empty collections are written as [] and {} so that they cannot be confused with null.

{
  "teams": [
    { "name": "api", "roles": [] },
    { "name": "web", "roles": ["reader"] }
  ],
  "options": {}
}

teams:
  - name: api
    roles: []
  - name: web
    roles:
      - reader
options: {}

Indentation defines which values belong to each map or sequence. Tools in a Tab uses two spaces and never tabs. If you edit the file later, maintain consistent indentation.

What a conversion from JSON cannot preserve

JSON does not contain YAML comments, anchors, aliases, tags, or presentation styles. The converter cannot recover information that was never in the input.

Duplicate names deserve a separate review. RFC 8259 recommends unique names within each JSON object, and readers can handle repetitions differently. This converter preserves each occurrence instead of hiding it, but YAML mappings require unique keys. Resolve duplicates in the source before using the output; the reverse YAML-to-JSON converter rejects them.

A round trip also does not preserve spaces, line breaks, or choice of quotes byte by byte. The goal is to maintain structure and types, not rebuild the original presentation.

Check a round trip

For an additional check, pass the result through the YAML to JSON converter. Within the supported subset, objects, arrays, strings, numbers, booleans, and null should return with the same types.

This test detects a string that was left unquoted or a collection that was incorrectly indented. It does not replace the validation of the final application: Docker, Kubernetes, a CI workflow or any other tool can require concrete properties and values in addition to valid syntax.

Checklist before using the YAML

• The original input was valid JSON.
• Ambiguous strings are still enclosed in quotes.
• Numeric identifiers are modeled as text when applicable.
• Large integers fit in the destination reader.
• The arrays retain the expected order.
• [], {} and null have not been confused with each other.
• There are no duplicate names left unresolved.
• The target application accepts the generated structure.

Privacy and tool limits

Conversion runs within this tab. Content is not sent to our servers, added to the URL, or saved to local storage.

Input is limited to 1,000,000 characters and 100 levels of nesting to protect the browser. For larger documents, use a local command-line tool and check the destination application’s supported types.

Technical references

The JSON types used in this guide are defined in RFC 8259. Maps, sequences, scalars and resolution schemas are described in the YAML 1.2.2 specification. All examples are checked against the published Tools in a Tab converters.