How to convert JSON to YAML without losing types

Short answer

Converting JSON to YAML without losing types requires preserving the meaning of each value, not just changing braces for indentation. A boolean must remain boolean, null should not be converted to text and a string like "1.0" should continue to be a string even if 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

Braces and commas disappear because YAML uses indentation, colons, and scripts to express structure. Rates do not change: 8080 remains a number, true a boolean, null a null value, and values in quotes They continue to be text.

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: no should be used to give meaning to a YAML map. If the order is part of the data, represent it using an array.

Secure conversion procedure

1. Confirm that the input is strict JSON. The comments, the quotes simple 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 it does not guarantee that it complies with your configuration scheme.

If the first step fails, use the validator JSON to locate the error before convert. Formatting the input is optional: the formatter JSON may make it more readable, but it does not change their types.

Quote strings that might look like another type

Unquoted scalars can be resolved as numbers, booleans, or values null. Additionally, some applications use their own schemes or rules to dates and other values. Keeping quotes prevents a string from changing type.

{
  "habilitado": "true",
  "vacio": "null",
  "codigo": "0042",
  "respuesta": "yes"
}

The result preserves all four values ​​as text:

habilitado: "true"
vacio: "null"
codigo: "0042"
respuesta: "yes"

Don’t remove those quotes just to shorten the file. "true" and true do not they mean the same thing; neither are "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 old YAML 1.1 rules. Even so, the converter quotes them so that the file be more robust against older readers or 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,
  "umbral": 1.25e+3,
  "cero": -0
}

id: 9007199254740993123456789
umbral: 1.25e+3
cero: -0

The second check belongs to the YAML consumer. The specification allows integers of arbitrary size, but a library or application can use native types with a smaller range. The decimals also depend on the precision available. If a figure functions as an identifier and not as quantity, modeling it as a chain usually better expresses your intention.

Preserving the type does not mean preserving the exact writing 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 are not be confused with null.

{
  "equipos": [
    { "name": "api", "roles": [] },
    { "name": "web", "roles": ["reader"] }
  ],
  "opciones": {}
}

equipos:
  - name: api
    roles: []
  - name: web
    roles:
      - lector
opciones: {}

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 persist

JSON does not contain comments, anchors, aliases, YAML tags or styles. presentation. The converter cannot recover information that was never in the entry and you should not invent it either.

Duplicate names deserve a separate review. RFC 8259 recommends that The names of a JSON object are unique, and different readers can process repetitions differently. The tool preserves the occurrences in the output so as not to hide them, but it is advisable to resolve the duplication in the origin before using the YAML.

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 the reverse traversal

For additional checking, pass the result through the YAML to JSON. In the compatible subset they must respawn objects, arrays, strings, numbers, booleans and null with the same classification.

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

The conversion is executed within this tab. Content is not sent to our servers, it is not added to the URL and it is not saved in storage local.

Input is limited to 1,000,000 characters and 100 levels of nesting to protect the browser. For larger documents, use a tool local command line and also check the types of the end consumer.

Technical references

The JSON types used in this guide are defined in RFC 8259. Maps, sequences, scalars and resolution schemes are described in the [YAML] specification 1.2.2](https://yaml.org/spec/1.2.2/). All examples are checked against the published Tools in a Tab converters.