CruxDevCruxDev Tools Prompts
dev Utility • Zero-Server Privacy • 100% Client-Side

YAML → JSON Schema Generator

Generate JSON Schema from YAML sample data with automatic type inference, required fields, and nested object support.

Overview

Infer a JSON Schema (draft-07) from a YAML sample. Types are detected per value, nested objects become properties with required lists, and arrays get an items schema from their first element. The schema updates live as you edit the sample.

How It Works

Paste a YAML document on the left; the inferred schema appears on the right as pretty-printed JSON with the draft-07 schema identifier at the top. Strings, integers, floats, booleans, nulls, arrays, and objects are each mapped to their schema equivalent, with objects listing all their keys as required. Download buttons export the sample and the schema file.

Step-by-Step Usage Guide

  1. Paste a representative YAML sample into the left editor.
  2. Read the inferred schema on the right and check each type mapping.
  3. Adjust required lists and widen types the single sample got wrong.
  4. Download the schema as JSON for use in your validator.

Technical Specifications & Standards

The inference walks the parsed YAML once per value. Scalars map directly: strings to string, booleans to boolean, null to the null type, and numbers split between integer and number depending on whether the sample value is whole. Arrays produce an items schema inferred from the first element only, and an empty array yields an empty items object, which means any item type. Every object marks all of its keys required, because with a single sample there is no way to know which fields are optional. Two consequences for real use. First, this is single-sample inference: a field that is sometimes a string and sometimes a number will come out as whichever the sample showed, and you should widen it to a union or drop the constraint by hand. Second, the YAML types come from the parser's resolution rules, so unquoted yes, off, or version-like values may resolve to booleans or floats unexpectedly; quote such values in the sample to force string. The emitted schema declares draft-07, which remains the most widely supported validator dialect.

Targeted Use Cases

  • Bootstrapping a config schema for a tool that reads YAML settings files.
  • Generating a starting schema to validate user-edited configuration files.
  • Documenting the structure of a YAML payload alongside examples.
  • Comparing intended structure against real samples before tightening validation.

Notes & Gotchas

  • Use the most complete sample you have, including every field at least once.
  • Edit the required list by hand; the tool marks every property required since it cannot see optional fields.
  • Quote values like version numbers or on/off strings in YAML so they infer as strings.
  • Widen array item types when elements vary; only the first element is inspected.

Frequently Asked Questions

Why is every property marked required?

Inference sees one sample, so it cannot know which fields are optional in practice. The schema lists all observed keys as required; relax that list before validating real documents.

How are empty arrays handled?

An empty array has no element to infer from, so its items schema is left empty, which matches any item type. Add a representative element to the sample to get a concrete items schema.

Which schema draft does it emit?

Draft-07, declared with the $schema key. It remains the most widely supported dialect across validators, even though newer drafts exist.

Why did my value infer as a boolean?

YAML resolves unquoted tokens like true, false, yes, and no as booleans. Quote the value in the sample if it is meant to be a string, and the schema will follow.