ToolLineup

Avro Schema Formatter and Validator

An .avsc file is JSON, so any formatter can indent it. What this adds is checking that the JSON is a valid Avro schema: a field typed "integer" instead of "int", a record with no name, a union listing the same type twice, or a nullable field whose default cannot apply are all perfectly good JSON and are all rejected by every Avro implementation. Each problem is reported with the path to the node that caused it.

How it works

An .avsc file is JSON, so any JSON formatter can indent it. What this one adds is checking that the JSON is a valid schema — a field typed "integer" instead of "int", a record with no name, or a union listing the same type twice are all perfectly good JSON and are all rejected by every Avro implementation.

The check covers naming rules, duplicate field names and enum symbols, dangling references to named types, array and map completeness, fixed sizes, and the rule that a union takes its default from its first branch — which is why a nullable field defaulting to null must list "null" first.

Everything runs in your browser — nothing you paste is uploaded.

Nothing pasted yet
Avro schema (.avsc)
Paste an Avro schema…
Formatted schema

Frequently asked questions

Why is a nullable field with a default of null sometimes rejected?

Avro takes a union default from the first branch of the union, so a field typed ["string", "null"] with a default of null is invalid — the default has to match the string branch. Listing "null" first fixes it, which is why the convention exists.

What errors does this catch that a JSON validator does not?

Anything that is well-formed JSON but not a valid schema: type names that do not exist such as "integer" instead of "int", records without a name or without fields, names that break Avro naming rules, duplicate field names or enum symbols, unions containing the same type twice or nested inside each other, arrays without items, maps without values, fixed types with no size, and references to named types that are never declared.

Why can a union not contain the same type twice?

Avro encodes a union value as an index into the union followed by the value. If two branches had the same type, a decoder could not tell which index a value belonged to, so the format forbids it outright.

Does the validator check my data against the schema?

No, it validates the schema itself. Checking records against a schema needs the data as well and is what an Avro library does at read and write time.

Why does it suggest adding doc strings?

Avro carries a "doc" field on records and fields that travels with the schema into the registry — which is the one place a consumer of your topic will actually look for an explanation of what a field means.

Related tools