Avro Schema Viewer
Explore and validate an Avro schema, with the canonical form and fingerprints that identify it — and warnings for the mistakes that a reader silently ignores rather than rejecting.
Drop a .avsc file here
Up to 2 MB · nothing uploaded
Paste or drop a schema to explore it.
{{ errorCount }} problem{{ errorCount === 1 ? '' : 's' }} found
Valid, with {{ warnCount }} thing{{ warnCount === 1 ? '' : 's' }} worth checking
Schema is valid
No problems found. {{ summaryLine }}
{{ summaryLine }}
- line {{ d.line }}, col {{ d.col }} — {{ d.path }} — {{ d.message }}
- {{ r.label }} {{ r.type }} {{ r.tag }} {{ r.doc }}
Nothing to show.
{{ m.name }}{{ m.kind }}
{{ m.doc }}
| {{ h }} |
|---|
| {{ cell }} |
No records or messages with fields.
-
{{ t.kind }}
{{ t.fullName }}{{ t.detail }}
No named types.
Unresolved references
{{ unresolvedNote }}
-
?
{{ u.type }}used by {{ u.field }}
Well-known types used
-
{{ w.name }}{{ w.note }} JSON: {{ w.json }}.
{{ fingerprints.canonical }}
Documentation, aliases, defaults and whitespace are removed and names are fully qualified, so two schemas that read data identically produce identical text here. Field order is kept, because it decides the binary layout.
| Fingerprint | Value |
|---|---|
| Rabin 64 (hex) | {{ fingerprints.rabin64Hex }} |
| Rabin 64 (unsigned) | {{ fingerprints.rabin64Unsigned }} |
| Rabin 64 (signed) | {{ fingerprints.rabin64Signed }} |
| MD5 | {{ fingerprints.md5 }} |
| SHA-256 | {{ fingerprints.sha256 }} |
The canonical form needs a schema that parses.
File-level features{{ edition }}
Editions replace the syntax keyword with individual features that inherit from the file to each message to each field. The "from" column is the part that is invisible in the source.
| Feature | Value | From |
|---|---|---|
{{ f.name }} | {{ f.value }} | {{ f.from }} |
No feature information — this file uses a syntax declaration rather than an edition.
{{ normalized }}
Printed back from the parsed structure with consistent formatting. Re-parsing this produces the same structure as your input — that equivalence is what the parser is tested against.
Nothing to normalise.
Your schema is parsed, validated and fingerprinted entirely in your browser. Nothing you paste is ever uploaded to a server.
The Avro mistakes that fail silently
Avro is unusually forgiving in the worst way: several kinds of malformed schema are not rejected,
they are ignored. A logical type attached to the wrong underlying type — decimal
on a string, say — must be ignored by a conforming reader, so your money column
quietly becomes an opaque string instead of failing loudly at deploy time. This viewer reports
those cases specifically, because nothing else will.
Union defaults are the classic trap
The specification requires a union field's default to match the first branch of
the union, not any branch. That makes ["null","string"] with a null
default correct and ["string","null"] with a null default wrong — a
one-word difference with real consequences for schema evolution, since a field without a usable
default cannot be added or removed compatibly.
Canonical form and fingerprints
Avro defines a normalised rewriting of any schema: full names everywhere, no documentation, aliases or defaults, object keys in a fixed order, no whitespace. Hash that and you get the fingerprint that identifies the schema. Two schemas that read data identically produce the same fingerprint no matter how differently they are written — which is how registries tell "this is the same schema" from "this is a new version".
One thing the canonical form does not do
It does not reorder the fields of a record. Field order decides the binary layout in Avro, so two records holding the same fields in a different order are genuinely different schemas and get different fingerprints. If you have ever wondered why a reordering "broke" compatibility, that is why.
Working with a .proto file instead?
Use the Protobuf Schema Viewer, which shows field presence, edition features and JSON name mapping.
Frequently asked questions
Why is my default value being ignored?
Almost always because it does not match the field type, and the commonest version of that is a union: the specification says a union field default must match the FIRST branch of the union, not any branch. A field typed ["string","null"] with a null default is invalid for that reason, while ["null","string"] with a null default is fine. This tool flags both cases.
What is the Parsing Canonical Form, and why would I want it?
It is a normalised rewriting of a schema defined by the Avro specification: full names everywhere, no documentation, defaults or aliases, keys in a fixed order and no whitespace. Two schemas that read data identically produce identical canonical forms, which is how a schema is identified and compared rather than by its raw text.
Do two schemas with the same fields in a different order match?
No, and this is a real trap. Field order in an Avro record determines the binary layout, so reordering fields produces a genuinely different schema with a different fingerprint. Only cosmetic differences — documentation, aliases, whitespace, the order of keys inside an object — collapse away in the canonical form.
What does a logical type warning mean?
A logical type only applies to specific underlying types: decimal on bytes or fixed, date on int, timestamp-millis on long, and so on. If it is attached to anything else the specification says a reader must ignore it, so your data silently loses its meaning instead of failing loudly. That is why it is reported here.
Which fingerprint should I use?
The 64-bit Rabin fingerprint is what Avro tooling uses by default and what appears in single-object encoding, so it is the one to match against other Avro tools. MD5 and SHA-256 are also defined by the specification and are shown for systems that expect them.
Is my schema uploaded anywhere?
No. Parsing, validation, canonicalisation and hashing all run in your browser. Nothing is sent to a server, which matters because a schema describes your internal data model.