Avro writer/reader schema compatibility
Check both resolution directions between local Avro JSON schemas, including promotion, aliases, defaults and incompatible results.
- 1Add input
- 2Adjust settings
- 3Get your result
Tool input and files are processed in this browser without being uploaded.
Before you start
Label the schema that wrote data and the schema expected by its reader. Review each resolution direction before accepting a field addition, rename or type change.
How to use this tool
- Supply the original writer schema and intended reader schema.
- Review writer→reader first, then the reverse direction and any underlying resolution error.
- Confirm supported schema and business value constraints before downloading JSON or CSV.
Supported inputs and limits
Writer schema: one UTF-8 file or pasted JSON; reader schema: secondary JSON input. Each is limited to 1 MiB,10000 JSON values and depth 32. A selected file takes precedence. Duplicate keys, nonfinite values and unsafe integers reject without rounding defaults.
Supports primitive, record, enum, fixed, array, map, union and named recursive schemas. Checks writer→reader and reader→writer separately, including full namespaces, reader aliases, defaults and numeric promotion. Fixed size is1..1048576; structural schema budget is10000 nodes/depth 32.
Pinned avsc5.7.9 requires a union field default to match its first branch; newer later-matching-branch defaults are unsupported. Every logicalType rejects. Protected identifier segments __proto__, constructor and prototype reject in names, namespaces, aliases, fields and enum symbols.
Reports schema resolution compatibility, without executing datum, IDL, registry policy, scripts or services, and without network requests. Only trusted library internal resolver generation runs inside a standalone same-origin HTTP Worker. Blob Worker and page codegen are blocked by production CSP. Underlying error text is not an invented exact field path. Both direction results and CSV are complete.
Worked example
Example input
{
"type": "record",
"name": "Contact",
"fields": [
{
"name": "id",
"type": "int"
}
]
}Example options
{"secondary":"{\n \"type\": \"record\",\n \"name\": \"Contact\",\n \"fields\": [\n {\n \"name\": \"id\",\n \"type\": \"long\"\n },\n {\n \"name\": \"label\",\n \"type\": \"string\",\n \"default\": \"\"\n }\n ]\n}"}Example output
{
"writerName": "Contact",
"readerName": "Contact",
"writerToReader": {
"direction": "supplied writer → supplied reader",
"compatible": true,
"resolutionError": null
},
"readerToWriter": {
"direction": "supplied reader → supplied writer",
"compatible": false,
"resolutionError": "cannot read \"long\" as \"int\""
},
"policy": "schema-resolution-only; no registry policy or datum execution"
}When something does not work
Correct JSON, schema names or defaults; handle unsupported logical types explicitly, then rerun the example. A valid false result can be downloaded and means that direction is incompatible.
Frequently asked questions
Does false mean invalid input?
Valid schemas can be incompatible in one direction. That produces a complete false report; malformed or unsupported schemas reject.
Does this check Schema Registry policy?
It checks the two supplied schemas, without historic registry versions or policy.
Are logical types and later-branch union defaults supported?
Logical types reject. Union defaults must match the first branch. Removing schema meaning deliberately changes the question being checked.
Documentation & further reading
Related tools
JSON formatting workspace
Format or minify strict JSON, sort object keys, and encode or decode strings while preserving raw number tokens.
Regex tester
Try a pattern and see what it matches in your text.
Compare text
See what changed, side by side.
HTML formatter
Format HTML indentation so its structure is easier to read.