Input

Output

What does Avro Schema to JSON Schema do?

You have an Apache Avro schema (.avsc) and the rest of the world wants JSON Schema. Maybe a frontend form library expects JSON Schema, maybe an API gateway validates request bodies against it, maybe you are documenting an event in an OpenAPI spec. Paste the Avro schema on the left and the right panel returns a JSON Schema (Draft 2020-12) that describes the same record — same fields, same required-vs-optional behavior, same nullable shape.

The mapping follows what most teams actually want. Avro record becomes a JSON Schema object with properties and a required array (every field without an Avro default is required). Avro enum becomes a string with an enum list of symbols. Unions like ["null", "string"] become anyOf. int and long become integer with the matching format hint per the Avro 1.11 specification. bytes and fixed become string with contentEncoding: "base64". Field-level doc annotations carry over to JSON Schema description, and Avro defaults end up as default on the corresponding property.

Everything runs in the browser. Your schema is parsed with the native JSON parser, walked once, and the result is rendered in the right panel. No upload, no telemetry, no schema stored anywhere.

How to Use Avro Schema to JSON Schema

Three quick steps. The buttons described below are the actual buttons on this page.

Paste, Upload, or Load a Sample

Paste an Avro schema into the left Input panel. Hit Upload for an .avsc file, or Sample to load a realistic Order schema with nested OrderItem records, an enum currency, and a nullable Address. Quick example of what minified Avro looks like:

{"type":"record","name":"Order","fields":[{"name":"orderId","type":"string"},{"name":"totalCents","type":"long"}]}

The right panel updates as you type — there is no Convert button. The result follows the keywords defined by RFC 8259 JSON and the JSON Schema 2020-12 vocabulary.

Read the JSON Schema

The right Output panel renders a JSON Schema with two-space indentation. The top-level record becomes an object with title and (if present) description. Fields with no Avro default land in the required array. Logical types like timestamp-millis reduce to their underlying physical type — Avro carries the semantics, JSON Schema does not have a one-to-one peer for every logical type.

Copy or Download

Hit Copy to grab the JSON Schema for an OpenAPI spec, an Ajv validator config, or a Schema Registry migration. Hit Download to save it as schema.json. Empty input clears the output cleanly — paste again and it converts again.

When You'd Actually Use This

Migrating from Avro to JSON Schema

Your team adopted Avro for Kafka events, but the new REST API needs JSON Schema for OpenAPI. Paste the Avro schema, get a JSON Schema you can drop straight into the OpenAPI components/schemas section. No hand-translation.

Frontend Form Generation

JSON Schema-driven form libraries (react-jsonschema-form, jsonforms, etc.) expect JSON Schema, not Avro. Convert the schema once and let the form render itself — fields are required, defaults are populated, enums become dropdowns automatically.

Bridging Avro and OpenAPI Documentation

You are documenting an Order event in OpenAPI 3.1, which uses JSON Schema as its schema vocabulary. Convert the Avro definition, paste it under the request/response schema, save the round of manual translation that nobody enjoys.

Validation Against a Different Toolchain

Your validation library speaks JSON Schema (Ajv, jsonschema in Python, justify, etc.) and not Avro. Convert the schema once, validate the same payloads with the JSON-Schema-native tool you already have.

Common Questions

How do you handle Avro unions like ["null", "string"]?

They become { "anyOf": [{ "type": "null" }, { "type": "string" }] } in the output. JSON Schema does not have a one-to-one peer for the "nullable string" idiom — anyOf is the most accurate translation and matches what Ajv and similar validators expect.

What about Avro logical types like decimal or timestamp-millis?

They reduce to the underlying physical type. timestamp-millis on a long becomes { "type": "integer", "format": "int64" }. decimal on bytes becomes a base64-encoded string. JSON Schema 2020-12 does not have first-class peers for these, so the closest physical mapping is what you get.

How is required determined?

Avro fields without a default become required. Fields with any default (including null) are not required, and the default value is carried over to the JSON Schema property as default. This matches what most consumer-side validators expect.

Does it follow named-type references?

Yes. When a record's name has been seen earlier, later references to that name produce { "$ref": "#/$defs/" }. You may want to manually move the inline definition into a $defs map at the top — the converter inlines on first occurrence, but the ref pattern is in place for re-use.

Is anything sent to a server?

No. Conversion runs entirely in your browser using JSON.parse and a recursive walker. Your schema never leaves the page.

Will it complain if my Avro schema is malformed?

JSON syntax errors are reported in the output panel. Structural Avro mistakes (records without fields, wrong primitive names, unresolved named types) are not validated here — for that, use the Avro Validator. The converter does its best with whatever you paste.

Other Avro and JSON Schema Tools

Schema conversion is one piece. These tools handle the rest: