Input

Output

What is the Avro Schema Formatter?

Run a normal JSON formatter on a .avsc and you get a pretty-printed file — but the keys come out in whatever order they happened to be in the input. doc floats to the top, type ends up buried under aliases, and every developer's editor saves the file slightly differently. Result: noisy diffs in Schema Registry pull requests where 80% of the lines changed are just key reorderings. This formatter fixes that.

Every object in the schema gets the same canonical key order: type first, then name, namespace, doc, aliases, fields, symbols, items, values, size, logicalType, default, then everything else alphabetically. The data is preserved exactly — same fields, same values, same nesting. Only the key order and the indentation change. Run this on every .avsc in your repo and your next schema PR shows only the lines that actually changed. Same idea as gofmt or black, scoped to Avro.

Everything runs in your browser. The schema is parsed with the native JSON.parse(), walked recursively, and re-emitted with two-space indentation. Nothing leaves the page, nothing is logged.

How to Use the Avro Schema Formatter

Three steps — paste, read, copy. 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. Click Upload to load an .avsc file from disk, or hit Sample for a realistic Order schema with nested records, an enum, and a union-typed shippingAddress. Quick example of what an unordered minified input looks like:

{"fields":[{"type":"string","name":"orderId"}],"name":"Order","type":"record","namespace":"com.example.commerce"}

The formatter handles both an .avsc schema file and the JSON encoding of an Avro record — both are JSON underneath, per RFC 8259. The full key-ordering ruleset comes from working with the Apache Avro 1.11 specification day to day.

Read the Formatted Output

The right Output panel renders the schema with two-space indentation and the canonical key order: type, name, namespace, doc, aliases, fields, symbols, items, values, size, logicalType, default, then everything else alphabetically. If the input is not valid JSON, the parse error shows up there instead so you can fix the typo first.

Copy or Download

Hit Copy to grab the formatted schema for a pull request or chat message. Hit Download to save as .avsc. Minify in the output panel collapses the schema to one line — useful when wiring a schema string into a config file or a Kafka producer config.

When You Would Actually Use This

Cleaner PR Diffs

Run every .avsc in your repo through the formatter once, commit the reformatted versions on a baseline commit, and then enforce it as a pre-commit hook. From that point on, schema PRs only show the fields that actually changed — not 80 lines of "key reordered" noise.

Reviewing Hand-edited Schemas

When a teammate hand-edits an Avro schema and stuffs doc in the middle of a record, you spend longer reading the diff than reviewing the change. Drop both versions into the formatter and the comparison gets dramatically easier.

Documenting an Event

Writing a wiki page about a new event your service emits? Run the schema through the formatter, paste it into the wiki. Type and name on top, fields in source order, the structure reads top-down naturally.

Onboarding a New Teammate

A new engineer reads a schema with random key order and they have to scan up and down the file to figure out what the record actually is. With canonical order, type and name lead, then doc, then fields. Onboarding becomes ten minutes shorter per schema.

Common Questions

How is this different from /avro-formatter?

The plain Avro Formatter just pretty-prints — it preserves whatever key order the input happened to have. This Schema Formatter applies a canonical Avro-aware key order so two semantically-identical schemas always serialize identically. Use this one when you want diff-friendly output.

Does it change my schema in any way besides key order and indentation?

No. The walker preserves every field, every value, every type. It just reorders keys and re-indents at two spaces. Round-tripping through this formatter and back through a JSON-equality check should always be a no-op semantically.

What's the exact key order?

type, name, namespace, doc, aliases, fields, symbols, items, values, size, logicalType, default, then any remaining keys in alphabetical order. Same order at every nesting level — record bodies, field definitions, enum bodies, fixed bodies.

Will it work on a JSON-encoded Avro record (not just a schema)?

Yes — both are JSON under the hood. It will reorder any object keys it finds. For a JSON-encoded record though, you probably do not want canonical key order; the field order in your record can carry meaning. For data records, use the regular Avro Formatter or JSON Formatter instead.

Is the formatted output always valid Avro?

If the input is valid Avro, yes. If the input has structural problems (a missing field name, an empty enum symbols array), the formatter still pretty-prints what is there — it does not validate. Use the Avro Schema Validator first if you want a structural check.

Are my schemas sent anywhere?

No. Parsing, walking, and re-emitting all run locally in your browser. Nothing is uploaded, nothing is logged. Safe for proprietary schemas.

Other Avro Tools

Formatting is one piece of working with Avro. These tools cover the rest: