Avro to Excel Converter
The file a pipeline handed you, in the format the person asking for it uses. The schema inside the container is read in your browser and the cells arrive already typed.
To convert Avro to Excel, drop your .avro file above. The container's embedded schema is read in your browser, each record becomes a spreadsheet row, nested records flatten into dotted columns, and each column is written with one cell type. The header row is frozen and the widths already fit.
Want to filter records before you export? Open the app
The format you meet once and cannot open
Avro turns up when a Kafka topic gets dumped to disk, when a Hadoop or Spark job writes its output, or when a partner sends an extract from a system built on the JVM. It is a good format and it is completely opaque without tooling.
The official route is the Avro tools jar, which means a Java runtime and a command line incantation you look up every time. That is a lot of ceremony to answer "what is in this file", and it is impossible on a machine where you cannot install a JDK.
And the person who actually needs the contents is frequently not the person with the tooling. An analyst has been sent the extract and works in Excel.
The schema travels with the file
An Avro container writes its schema into its own header, which is the format's best feature and the reason this conversion can be exact rather than inferential.
That schema names every field and its type, so a long is known to be an integer, a double is known to be a double, a boolean is known to be a boolean, and a string is known to be a string. Those come through to the workbook as numeric cells, boolean cells and text cells respectively.
A padded reference code declared as a string in the schema arrives as a text cell with its zeros intact, because there is no inference step in which they could be lost. That is a stronger guarantee than any CSV-based route can offer.
Nested records, unions and the flattening
Avro records nest, and pipeline schemas nest heavily. A nested record becomes dotted columns, so a customer record with a name inside it becomes customer.name. Past four levels the value is kept as JSON text in one cell, because a spreadsheet header of six-part names is not readable.
A union type, which in practice is nearly always ["null", "string"] and means an optional field, comes through as the value or as an empty cell. That is exactly what a spreadsheet wants and it is the most common construction in any real Avro schema.
An array field is kept as JSON text in a single cell rather than being spread into extra rows, so the workbook has exactly as many rows as the container has records. A row count that silently differs from the source is a spreadsheet whose totals nobody should trust.
Logical types, and one honest limitation
Avro layers logical types on top of primitives: a date is an int counting days, a timestamp-millis is a long, a decimal is bytes with a scale. Where the reader can recognise these they come through as readable values rather than raw integers.
Where it cannot, you get the underlying primitive, which is honest and occasionally surprising: a column of large integers that are really microsecond timestamps. The column names usually make that obvious, and converting them in the spreadsheet is a formula rather than a re-export.
If the file is one you will convert regularly, doing the logical-type conversion in the pipeline that writes it is worth more than doing it in every spreadsheet afterwards.
Nothing is uploaded, and that is the point
The hosted converters for these formats all want the file. That is a fine trade for a photograph and a poor one for a database extract, which is what these files almost always are: customer tables, transaction detail, event streams with identifiers in them.
Everything here runs inside the page. The file is read by JavaScript in your tab, the output is built there, and the download comes out of memory. Nothing is sent, stored or logged, and once the page has loaded the tool works with the network off.
The practical ceiling is your tab's memory rather than an upload quota. Past a hundred megabytes or so the full editor streams and is the better route.
Frequently Asked Questions
Do I need Java or the Avro tools jar?
No. The container is read in your browser. That is the whole point: the official route needs a JVM and a command you look up every time, and it is impossible on a machine where you cannot install one.
Where do the column types come from?
The schema written into the container's own header. A long is an integer, a double is a double, a boolean is a boolean, a string is a string. Nothing is inferred, so a padded code declared as a string keeps its zeros with no possibility of loss.
How are nested records handled?
They flatten into dotted columns, so a nested customer becomes customer.id and customer.name. Nesting past four levels is kept as JSON text in one cell, because a spreadsheet header of six-part names is unreadable.
What about optional fields?
An Avro union of null and something else, which is how optional fields are almost always written, comes through as the value or as an empty cell. That is exactly what a spreadsheet wants.
Will the workbook have the same number of rows as the file has records?
Always. An array field is kept as JSON text in one cell rather than spread into extra rows, because a spreadsheet whose row count differs from the source is one whose totals cannot be trusted.
Why is a timestamp column showing large integers?
Because the schema declared it as a long with a logical type the reader could not map. Avro stores timestamps as integers, and where the logical type is recognised you get a readable value. When it is not, you get the underlying primitive, which is honest rather than guessed.
Open the Avro file
Schema read from the container, typed cells, no JVM and no upload.
Back to the converter