Does this read any of the actual row data?

No. Only the file's footer metadata is read, which is where Parquet stores row counts, row group boundaries, and writer information, no column data pages are decoded.

What is a "row group", and why does the count matter?

A Parquet file's rows are physically split into one or more row groups, each an independently readable chunk. More row groups generally means better support for parallel or partial reads, while a single huge row group can make certain operations less efficient.

How is this different from the Parquet Schema Reader?

This tool answers file-level questions: how many rows total, how many row groups, who wrote it, and how large the data is. The Parquet Schema Reader instead answers column-level questions: what columns exist and what type each one is. Use this one for file statistics, the other for column structure.

Why might "Created by" show "Not recorded"?

The created_by field is optional in the Parquet format. Some writers omit it, in which case there's genuinely no writer information embedded in the file, this isn't a parsing error.

Parquet Metadata Reader - File Stats Online

Overview

Introduction

Before opening a Parquet file in a full data tool, it's often useful to know a few basic facts about it: how many rows it has, how it's physically chunked, and what wrote it. This tool surfaces exactly that from the file's footer.

Upload a .parquet file and get a small stats card: total rows, row group count, the writer's identifying string if present, and total uncompressed byte size, all read from metadata alone.

What Is Parquet Metadata Reader?

A Parquet file-level metadata reader that parses only the footer, the compact block at the end of every Parquet file holding row counts, row group layout, schema, and optional writer information, without touching any column data pages.

It reports the numbers Parquet itself already tracks as part of its format: total row count, row group count, the created_by string (if the writer set one), and the sum of each row group's total uncompressed byte size.

How Parquet Metadata Reader Works

The uploaded file is wrapped as an in-memory buffer, and its footer metadata is read using a Parquet metadata parser, giving direct access to the file's `num_rows`, `row_groups` array, and optional `created_by` string.

Row count and each row group's byte size are read as 64-bit values (JavaScript bigint under the hood) and converted to regular numbers for display, with the per-row-group byte sizes summed into a single total.

When To Use Parquet Metadata Reader

Use it as a quick sanity check on a Parquet file before committing to a full read: is the row count what you expected, does the file look freshly written or old, how large is the actual data.

It's also useful when debugging a data pipeline, confirming how many row groups a writer produced, or spotting a suspiciously small (possibly truncated or empty) output file.

Often used alongside Parquet Schema Reader and Parquet Reader and Viewer.

Features

Advantages

Reads only the footer, so it's fast even on very large Parquet files since no row data is decoded.
Surfaces exactly the statistics the Parquet format itself already tracks, no estimation or sampling involved.
Works entirely client-side, no upload or server round trip required.

Limitations

Total byte size reflects uncompressed data as recorded in the row group metadata, not the file's on-disk compressed size.
The created_by field is optional in the format; many writers simply don't set it, which shows as "Not recorded" here rather than an error.

Examples

Reading a small Parquet file's metadata

Input

(a .parquet file with 1,200 rows across 2 row groups, written by pandas)

Output

Total rows: 1,200
Row groups: 2
Created by: pandas
Total uncompressed byte size: 48.3 KB

All four values come directly from the file's footer metadata, no row data needs to be decoded to produce them.

Best Practices & Notes

Best Practices

Check this tool before a full conversion on an unfamiliar file, so a surprisingly large row count doesn't catch you off guard mid-conversion.
Pair with the Parquet Schema Reader for a complete picture: this tool for file-level stats, that one for column structure.
Compare row-group count against total row count for an unfamiliar file, a very high row-group count for a small file can indicate it was written inefficiently.

Developer Notes

Row count and per-row-group byte sizes come back from the Parquet reader as `bigint` (since Parquet's format spec defines them as 64-bit integers), so each is explicitly converted with `Number()` before summing or formatting, rather than risking a `TypeError` from mixing `bigint` and `number` arithmetic.

Parquet Metadata Reader Use Cases

Confirming a Parquet file's row count and size before committing to a full read or conversion
Debugging a data pipeline by checking how many row groups a writer produced
Spotting a suspiciously small or empty Parquet file before investigating further

Common Mistakes

Reading "Not recorded" for Created by as a parsing failure, it usually just means the writer didn't set that optional field.
Confusing total uncompressed byte size shown here with the file's actual on-disk (compressed) size, which is typically smaller.

Tips

Use the row group count alongside total rows to estimate average rows per group, useful context when reasoning about a file's read performance.
If total rows here differs from what you expected, double-check you uploaded the right file before debugging further downstream.

Parquet Metadata Reader