JSON to Avro Schema Generator
Convert JSON objects into Apache Avro schema definitions instantly. Generates valid Avro 1.8+ record schemas with correct type mappings, nullable union types for null fields, nested record types, and array types — ready to register in Confluent Schema Registry or use directly with Kafka producers and consumers.
Convert JSON objects into Apache Avro schema definitions instantly. Generates valid Avro 1.8+ record schemas with correct type mappings, nullable union types for null fields, nested record types, and array types — ready to register in Confluent Schema Registry or use directly with Kafka producers and consumers.
This tool is designed to provide a seamless experience for developers by handling complex operations directly in your browser with maximum speed and security.
Apache Avro is a data serialization framework developed within the Apache Hadoop project. It defines a schema using JSON for the schema definition format, but serializes the actual data in a compact binary format rather than text. A JSON object with three string fields might take 80 bytes as UTF-8 JSON — the equivalent Avro binary representation is closer to 20 bytes because field names are not repeated in the data, only the values are written. The schema is consulted separately during deserialization to know what the values mean. This compact binary format is one of the main reasons Avro is preferred over JSON for high-throughput data streaming systems like Apache Kafka.
Avro's schema system is its defining feature beyond compact encoding. Every Avro record has an explicit schema that defines: the namespace (like a package or database name), the record name, and the list of fields each with a name, a type, and optionally a default value. Avro primitive types are null, boolean, int, long, float, double, bytes, and string. Complex types include record (nested objects), array (lists), map (key-value pairs), union (multiple possible types for a field), enum, and fixed. The union type is particularly important — nullable fields in Avro are represented as a union of null and the actual type: ["null", "string"] means the field can be either null or a string. This explicit nullability is more precise than JSON where any field can be null or absent without schema declaration.
Schema evolution is the feature that makes Avro especially valuable in production data pipelines. When a schema changes over time — a field is added, removed, or its type is changed — Avro defines rules for whether the change is backward compatible (new readers can read data written with the old schema), forward compatible (old readers can read data written with the new schema), or fully compatible (both directions). Confluent Schema Registry, used with Kafka, enforces these compatibility rules when a new schema version is registered, preventing incompatible schema changes from breaking downstream consumers. This governance is invisible when you just need a schema for a new topic, but it becomes critical when the topic has been running in production for months with thousands of consumers.
Read the Full GuideThis tool takes a JSON object and generates a valid Apache Avro schema definition from it. It infers the Avro type for each JSON field: JSON strings become "string", integers become "long" (Avro's 64-bit integer, which safely holds all JSON integer values), floats become "double", booleans become "boolean", JSON null values become a nullable union ["null", "string"] or the appropriate nullable union based on context, JSON arrays become array types with the element type inferred, and nested JSON objects become nested record types. For nested objects, the tool generates a separate named Avro record type for each nesting level and references it correctly in the parent schema. The generated schema follows the Avro 1.8+ format that Confluent Schema Registry and the Apache Avro libraries for Java, Python, and Go all accept. Each field includes a default value where one can be inferred — null fields default to null, string fields default to an empty string, and so on. The generated JSON is valid Avro schema JSON that can be registered directly in the Confluent Schema Registry API or pasted into an Avro-based Kafka producer or consumer configuration. The record name defaults to a generated name based on the structure. Before using the schema in production, you should rename it to a meaningful name that reflects the domain — User, Order, ClickEvent, PaymentTransaction — and set the namespace to match your organization or team's namespace convention (com.yourcompany.events, io.yourteam.models). The namespace and record name together form the fully qualified name that Confluent Schema Registry uses to identify schema subjects and manage evolution.
1. Paste your JSON into the Input JSON field — use a representative sample of the data payload you need to serialize with Avro. A single JSON object works best. If the event payload contains different fields in different messages (some fields present, some absent), use the most complete sample that includes all possible fields, since the generated schema will only include fields that appear in your sample. Click Load Example to see a sample nested JSON before using your own data.
2. Click Convert to Avro Schema — the tool parses every field, infers the Avro type, generates nullable unions for null fields, creates nested record definitions for nested objects, generates array types for JSON arrays, and outputs the complete Avro schema JSON in the result panel. The generated schema is valid Avro 1.8+ JSON that Schema Registry will accept.
3. Review the generated schema carefully — update the record name from the generated placeholder to a meaningful domain name like User, OrderEvent, ClickEvent, or PaymentTransaction. Update the namespace to match your organization's convention: com.yourcompany.events or io.yourteam.models. The namespace and record name together form the fully qualified schema name used by Schema Registry for versioning and compatibility tracking.
4. Review the inferred types for accuracy — JSON integers are mapped to Avro "long" (64-bit). If your data always contains small integers that should be Avro "int" (32-bit), change the type. Check that nullable fields are correctly represented as union types ["null", "actual_type"] with "default": null. If a field appears as a non-null value in your sample but can be null in real data, manually change it from "string" to ["null", "string"] with "default": null.
5. Copy the schema JSON and register it in your Schema Registry or save it to your project — use the copy button to copy the schema to your clipboard. Register it via the Confluent Schema Registry API (POST /subjects/your-topic-value/versions) or paste it into your Avro producer configuration, your schema file in your project, or your data contract repository.
Every time a new Kafka topic is created that carries structured data, someone has to write the Avro schema. For a team that uses Confluent Schema Registry and Avro-encoded topics, this is a mandatory step before any producer can publish messages. Writing the schema by hand is straightforward in theory but tedious in practice — you need to know the Avro type for every field, handle nullable fields with the union syntax, create nested record definitions for each embedded object, and get the JSON syntax of the schema definition exactly right or the Schema Registry will reject it. For a message payload with 20 fields and 3 nested objects, writing the schema takes 20–30 minutes. This tool does it in 10 seconds. The nullable union type is the specific part of Avro schema writing that catches most people who are new to Avro. In JSON Schema or Protobuf, marking a field as optional is a single annotation. In Avro, a nullable field must be declared as a union type: {"name": "email", "type": ["null", "string"], "default": null}. Forgetting the union, using just "string" for a nullable field, or getting the order of the union members wrong (null must be first for the default to be null) all cause Schema Registry rejections or serialization errors. This tool handles the nullable union correctly for JSON null fields automatically. For data engineers starting a new streaming pipeline — a new Kafka topic for order events, user activity events, or sensor readings — the workflow with this tool is: take a sample payload from the system that will produce the events, paste it here, get the Avro schema scaffold, update the record name and namespace, adjust any type overrides (a field that should be int not long, a field that should be an enum not a string), register the schema, configure your producer. You are writing the schema with the structure inference done — which is the mechanical part — rather than writing the entire schema from scratch.
Correct nullable union types — JSON null fields generate the proper Avro nullable union syntax ["null"
"string"] with "default": null which is exactly what Schema Registry requires and what most new Avro users get wrong
Avro 1.8+ compatible — generated schema JSON passes validation in Confluent Schema Registry and is compatible with the Apache Avro libraries for Java Python Go and Scala
Nested record decomposition — generates separate named Avro record types for nested JSON objects and references them correctly in the parent schema
Array type generation — JSON arrays generate proper Avro array type definitions with the element type correctly inferred
Correct Avro type mapping — JSON integers map to Avro "long" (64-bit) to safely handle all JSON integer values JSON floats map to "double" and JSON booleans map to "boolean"
100% browser-based — your JSON payload data including sensitive event content and internal data model structures never leaves your machine
Instant generation — all type inference and schema generation runs locally in your browser with no server round-trip
Schema Registry ready — the generated JSON can be registered directly in Confluent Schema Registry via the REST API without modification beyond renaming the record and namespace
Generating Avro schema definitions for new Kafka topics to register in Confluent Schema Registry
Bootstrapping Avro schemas for event-driven microservices that publish domain events to Kafka topics
Creating Avro schemas for Apache Spark structured streaming jobs that consume Kafka topics
Generating schema definitions for Apache Flink streaming jobs that read Avro-encoded Kafka messages
Creating Avro schemas for data landing zones in Apache Hadoop or Amazon S3 using Avro as the storage format
Bootstrapping Avro schema definitions for ksqlDB stream or table CREATE statements
Generating Avro schemas for Debezium CDC (Change Data Capture) event payload formats
Converting existing JSON REST API response structures to Avro schemas for event streaming migration projects
Example Input
{
"id": 1,
"name": "Priya Singh",
"email": "priya@learnhubly.com",
"isActive": true,
"score": 98.5,
"tags": ["developer", "admin"],
"deletedAt": null
}Example Output
{
"type": "record",
"name": "AutoGeneratedRecord",
"namespace": "com.example",
"fields": [
{"name": "id", "type": "long"},
{"name": "name", "type": "string"},
{"name": "email", "type": "string"},
{"name": "isActive", "type": "boolean"},
{"name": "score", "type": "double"},
{"name": "tags", "type": {"type": "array", "items": "string"}},
{"name": "deletedAt", "type": ["null", "string"], "default": null}
]
}
// Before using: rename "AutoGeneratedRecord" and "com.example"
// to match your domain and organization namespaceInvalid JSON Input: The tool requires valid JSON before generating an Avro schema. If your JSON has syntax errors — missing commas, unquoted keys, trailing commas, or single quotes — the conversion fails before any schema is generated. Use the JSON Formatter and Validator tool to fix syntax errors first, then paste the corrected JSON here.
Complex Nesting Requires Type Name Review: Highly nested JSON generates deeply nested Avro record definitions where each nesting level becomes a separate record type. The generated names for nested record types are auto-generated based on the field name and nesting level. Before registering the schema in Schema Registry, review and rename all nested record types to meaningful names — a nested address object should be named Address not NestedRecord0. Schema Registry identifies schemas by their fully qualified name (namespace.RecordName) so naming matters for schema subject management and evolution tracking.
Large JSON Objects Generate Long Schemas: Very large JSON objects with many fields generate correspondingly long Avro schemas. This is correct behavior — Avro requires every field to be declared. For large schemas, validate the generated JSON against the Avro specification using the Avro tools jar or the avro-python3 library before registering it: avro.schema.parse(schema_string) in Python or new Schema.Parser().parse(schemaString) in Java.
Nullable Union Field Order Matters: In Avro, when a nullable field uses a union type, null must be the first member of the union if the default value is null. The generated schema correctly puts null first: ["null", "string"]. If you manually edit the generated schema and accidentally reverse the order to ["string", "null"] with a default of null, Schema Registry will reject the schema because the default value must be of the type of the first union member. Always keep null as the first union member for nullable fields with null defaults.
Schema Registry Compatibility Check Failure: If you register the generated schema as a new version of an existing schema subject and Schema Registry rejects it with a compatibility error, the new schema is not compatible with the previous version under the subject's configured compatibility mode. Common causes: removing a field that was required in the previous schema (backward incompatible), changing a field type from string to long (not backward compatible), or adding a required field without a default value (not backward compatible). Add default values to all new fields and avoid changing existing field types to maintain backward compatibility.
Using 'string' for nullable fields instead of the union type
Fix: In Avro, a field that can be null must be declared as a union type: {"name": "email", "type": ["null", "string"], "default": null}. Declaring it as just "type": "string" means the field cannot be null — any message where that field is null will fail serialization with a schema violation error. This is the most common Avro schema mistake for developers coming from JSON Schema where optional fields are handled differently. This tool generates the correct nullable union syntax automatically for JSON null fields. If you manually edit the schema to add new nullable fields, always use the union syntax with null first.
Registering the schema without setting a meaningful record name and namespace
Fix: The namespace and record name in an Avro schema are not cosmetic — they form the fully qualified name (namespace.RecordName) that Confluent Schema Registry uses to identify schema subjects and track schema evolution history. A schema registered with name AutoGeneratedRecord and namespace com.example will have a subject history under that name forever. If you later try to rename it, you must register it as a new, separate subject with no evolution history. Always rename the record and set the correct namespace before the first registration. Use a naming convention like com.yourcompany.domain.EventName — for example com.acme.payments.PaymentTransaction.
Assuming Avro 'int' and JSON integers are the same
Fix: JSON integers have no defined size limit — they can be arbitrarily large. Avro's 'int' type is a 32-bit signed integer (maximum value 2,147,483,647). Avro's 'long' type is a 64-bit signed integer (maximum value 9,223,372,036,854,775,807). This tool generates 'long' for all JSON integer fields because it is safe — a long holds any value an int can hold plus much more. If you manually change a generated 'long' field to 'int' for storage efficiency, verify that the actual data values never exceed 2,147,483,647. Twitter-style IDs, Unix timestamps in milliseconds, and any auto-incrementing ID in a large database will exceed the int range.
Making breaking schema changes without understanding Avro compatibility rules
Fix: Confluent Schema Registry enforces schema evolution compatibility rules when new schema versions are registered. The default compatibility mode is BACKWARD — new readers (using the new schema) must be able to read data written with the old schema. BACKWARD compatible changes include: adding a new field with a default value, removing a field that had a default value, and widening a numeric type (int to long). BREAKING changes that violate backward compatibility include: removing a required field (no default), adding a required field without a default, renaming a field, and changing a field type to an incompatible type. Before making schema changes, run them through the Schema Registry compatibility check API: POST /compatibility/subjects/your-subject/versions/latest.
Using Avro schema where Protobuf or JSON Schema would be more appropriate
Fix: Avro is the right choice when: you are using Apache Kafka with Confluent Schema Registry (Avro is its native format and has the most mature tooling), you need compact binary serialization for high-throughput streaming, and you need built-in schema evolution governance. Protobuf is better when: you need cross-language support with strongly typed generated code, you are building gRPC services, or your team already has Protobuf infrastructure. JSON Schema is better when: you are validating HTTP API request and response bodies, you need human-readable schema documentation, or your system already stores JSON. Do not use Avro for REST API validation or configuration files — it adds complexity without the benefits that Avro provides in streaming contexts.
JSON Cheatsheet
Interactive reference guide for valid JSON syntax, data types, parsing/stringifying methods, schema validation rules, and language integrations.
Regex Cheatsheet
Interactive guide to Regex anchors, character classes, quantifiers, lookarounds, capturing groups, and search flags.
HTTP Headers Cheatsheet
Complete guide to standard and security HTTP headers including Authorization, CORS control, caching policies, and CSP directives.
SQL Cheatsheet
Complete guide to SQL statements including SELECT queries, WHERE filters, aggregate functions, JOIN types, and DDL commands.
Does it support Avro 1.8?
Yes. The generated schemas are compatible with Apache Avro 1.8 and later, including the current Avro specification. The schema JSON format uses the standard Avro schema definition syntax recognized by the Apache Avro Java library, avro-python3, the Go Avro library, Confluent Schema Registry, and all other Avro-compatible tooling. The generated schemas pass validation with avro.schema.parse() in Python and new Schema.Parser().parse() in Java.
Can I customize the record name?
Yes. The generated schema uses a placeholder record name and namespace. Before registering or using the schema, edit the 'name' field to a meaningful domain name like User, OrderCreated, PaymentTransaction, or ClickEvent, and edit the 'namespace' field to your organization's convention like com.yourcompany.events. The namespace and name together form the fully qualified schema name that Confluent Schema Registry uses for subject identification and schema evolution tracking. Choosing good names before the first Schema Registry registration is important because renaming requires creating a new schema subject.
Is it safe for sensitive data?
Yes. All JSON parsing and Avro schema generation runs entirely in your browser using JavaScript. Your JSON payload data — including event payloads that may contain internal data model fields, business logic indicators, or operational metadata — never leaves your machine and is never transmitted to any server. This is relevant for organizations where the structure of their Kafka event payloads is considered proprietary or sensitive operational information.
What is the difference between Avro and JSON for Kafka?
JSON Kafka messages store field names in every message — a message with 10 fields repeats all 10 field names in every event. Over millions of events, this adds up to significant storage and network overhead. Avro Kafka messages store only the values, not the field names, because the schema is stored separately in Schema Registry and looked up by schema ID. A compact Avro binary message can be 5-10x smaller than the equivalent JSON message. Avro also enforces schema compliance at produce time — a producer trying to send a message that does not match the registered schema gets an error immediately, whereas JSON messages can silently have wrong types or missing fields.
How do I register the generated schema in Confluent Schema Registry?
Use the Schema Registry REST API: POST to /subjects/your-topic-name-value/versions with Content-Type application/vnd.schemaregistry.v1+json and body {"schema": "your-avro-schema-as-escaped-json-string"}. The schema string must be the entire Avro schema JSON escaped as a single string value. With curl: curl -X POST -H 'Content-Type: application/vnd.schemaregistry.v1+json' --data '{"schema": "{\"type\":\"record\",\"name\":\"...\"}' http://your-registry:8081/subjects/your-topic-value/versions. The response is the schema ID assigned by Schema Registry, which Kafka producers include in each message header so consumers know which schema to use for deserialization.
What is schema evolution and why does it matter?
Schema evolution is the ability to change a data schema over time while maintaining compatibility between producers and consumers that may be using different schema versions simultaneously. In Kafka, producers write events and consumers read them — they may not be deployed at the same time. If the producer is updated to use a new schema but the consumer is still running with the old schema, they must still be able to communicate. Avro schema evolution rules define which changes are safe: adding a field with a default value is backward compatible (old consumers ignore the new field), removing a field that had a default is also safe, but adding a required field without a default breaks old consumers that do not know how to read the new field. Confluent Schema Registry enforces these rules by rejecting incompatible schema registrations.
Can I use the generated schema with Apache Spark, Flink, or other processing frameworks?
Yes. The generated Avro schema works with any framework that supports Apache Avro. In Apache Spark, use spark-avro (included in Spark 2.4+): spark.read.format('avro').option('avroSchema', schemaString).load(path). In Apache Flink, use the Avro format with Confluent Schema Registry: new AvroDeserializationSchema(MyClass.class) or with the generic record approach using AvroDeserializationSchema.forGeneric(schema). In Kafka Streams, use SpecificAvroSerde or GenericAvroSerde with the Schema Registry URL configured. The schema generated by this tool is the same schema format all these frameworks expect.
What is the difference between Avro, Protobuf, and JSON Schema for Kafka?
All three are supported by Confluent Schema Registry. Avro is the most mature and widely deployed — it has the most complete Schema Registry integration and the largest ecosystem of Kafka-specific tooling. It uses JSON for schema definitions but binary for data. Protobuf (Protocol Buffers) provides strongly typed generated code in many languages and integrates well with gRPC. It has slightly better performance than Avro in some benchmarks. JSON Schema validates the structure of JSON messages without binary encoding — messages stay as JSON text, which is larger but human-readable. For new Kafka projects starting from scratch, Avro with Schema Registry is the most battle-tested choice. If your team already has Protobuf infrastructure or is building gRPC services alongside Kafka, Protobuf is a reasonable alternative.
Mapping JSON to Avro: Why Schema Registry Matters for Kafka Streams – Complete Guide 2026
Mapping JSON to Avro for Kafka Streams in 2026: Why Schema Registry is essential for schema evolution, performance, and data governance. In-depth guide with real-world architecture, code examples, benchmarks, and expert recommendations from a Principal Software Engineer with 15+ years experience.
How to Convert JSON to Dart Classes for Flutter – Complete In-Depth Guide (2026)
How to convert JSON to Dart classes for Flutter in 2026. In-depth guide covering Dart model best practices, null safety, immutable classes, code generation with json_serializable & freezed, Flutter integration with Riverpod, and real-world architecture tips from a Principal Software Engineer with 15+ years experience.
What is JSON? How to Format, Validate & Use It (Complete Guide 2026)
What is JSON? How to Format, Validate & Use It (Complete Guide 2026). In-depth explanation of JSON syntax, real-world use cases, formatting best practices, common mistakes, advantages, disadvantages, and expert tips from a Principal Software Engineer with 15+ years experience.
Recent Activity
No recent activity