Parquet Inspector

A data export may contain the expected number of records while still storing an identifier as the wrong type or using a compression method that another application cannot read. Apache Parquet records those storage choices alongside the data. It is a binary, columnar file format used for tabular datasets, with values organized by column so readers can retrieve relevant fields without reconstructing every field in every row.

The schema describes the fields and their types. A physical type identifies the stored representation, such as a 64-bit integer or a byte array. A logical type adds meaning, such as interpreting bytes as UTF-8 text or an integer as a date. This distinction matters when moving data between systems. A field named customer_id does not establish its type, and an integer that represents a timestamp needs its declared time interpretation.

Rows are divided into row groups. Each row group contains a column chunk for each stored column, and each chunk contains pages of encoded values. That organization lets a reader locate a particular column within a particular range of rows. A row group is a logical grouping; the contiguous storage unit for an individual column is its column chunk.

Encoding and compression describe different operations. Dictionary encoding can replace repeated values with references to a shared list. A compression codec, such as Snappy, then compresses page data. The same column can use both. Repetition, text length, encoding choices, and compression all affect the bytes needed for a group of rows, so equal row counts do not imply equal storage sizes.

Inspection is useful when checking an export after a schema change, investigating unexpectedly large files, or confirming that identifiers and missing values survived a transfer. Null means a value is absent; an empty string is present text with no characters. A small preview can reveal these differences, but consecutive rows are not necessarily representative of an entire dataset. One file may also be only one part of a larger collection.

The file metadata provides declared types, row counts, codecs, and byte locations before the values themselves are decoded. Reading that metadata does not prove that every page is readable or that the records are complete and correct. Successful decoding of a selected range gives evidence about that range. A failure can indicate damaged data, an unsupported feature, or a reader limit, so rejection alone does not establish that a file violates the Parquet format.

How to Use This Tool:

Open one local file, inspect its structure, then choose which values to decode. The initial row window starts at row 0 and requests 100 rows.

1. Choose Browse file or drop one Parquet file of up to 32 MiB. Inspect sample provides a built-in example. Metadata is read automatically, and Schema catalog shows each column's preview eligibility.
2. Select the fields you need under Preview columns. Up to the first 32 eligible columns are selected initially. Unavailable columns have an explanation in Schema catalog.
3. Open Advanced to set First row (zero-based) and Preview rows. Row 0 is the first record. Choose a whole-number count from 1 to 1,000 and a starting position inside the file. A request extending beyond the last row returns only the remaining rows.
   Opening another file or using Clear keeps the row-window settings. If preview is unavailable, check that at least one supported column is selected and that the starting row is below the new file's row count.
4. Choose Preview selected rows. Check the inclusive row positions and selected-column count in the summary before using Selected preview. Changing the file, columns, or row window removes the previous preview and requires another preview before exporting it.
5. Copy or download the result you intend to keep. Preview exports contain only the selected columns and returned rows. Structural tables export their own current contents; Column-chunk detail group changes the group shown in Column chunks, without changing the preview window.

Interpreting Results:

File inspected means structural metadata was read. A column marked Supported has passed the schema, type, and codec checks for preview, but its pages still have to decode successfully within the processing limits. If preview fails, use the error and the column's declared type, codec, and encodings to choose a compatible reader or a smaller supported selection.

• Row groups reports declared row counts and storage sizes, with group numbering starting at 0. Compare the total with the records expected from the producing application.
• Column chunks shows all columns for the chosen detail group, including columns excluded from preview. Data and dictionary offsets are byte positions in the file. Values is a column value count and should not be treated as the dataset's row count for repeated or nested fields.
• File metadata includes the file size, format version, producer, and custom entries. Producer and custom text are declarations stored in the file, not authenticated provenance. Not recorded means that information was absent.

A valid file with zero rows has no row preview. An unavailable or failed preview does not establish that the dataset is empty; structural metadata may still be available. The reported reason distinguishes an unsupported feature, a processing limit, and a parsing failure. The inspection is read-only and does not run SQL, edit Parquet files, or convert a whole dataset.

Reading values without losing their meaning

Signed 64-bit integers remain exact decimal text, including values beyond the usual safe integer range of 9,007,199,254,740,991. JSON therefore contains strings such as "9007199254740993", even when smaller integers in the same column could fit in an ordinary number. CSV preserves the digits, but an application importing them as numbers may round them. Import those columns as text when every digit matters.

Booleans and 32-bit integers retain their boolean or numeric values in JSON. Finite floating-point values remain numbers with the precision of the stored binary value. A decimal fraction may already have been approximated when written as a 32-bit FLOAT or 64-bit DOUBLE. Nonfinite values use the literal string markers [NaN], [+Infinity], and [-Infinity]; these are not JSON numeric values.

The table displays a missing value as NULL and zero-length text as Empty string. JSON preserves these as null and "". CSV turns both into an empty field, so it cannot preserve that distinction. JSON contains the selected row objects rather than the Parquet schema. Consult the schema to distinguish an INT64 string or a floating-point marker from ordinary text. These exports are readable selections, not a lossless replacement for the original file.

Reading the storage curve

Storage distribution compares cumulative row share with cumulative compressed column-chunk byte share at row-group boundaries, in file order. Above Equal share, the groups accumulated so far account for a larger share of bytes than rows; below it, they account for a smaller share. The curve covers all column chunks, independently of the preview selection. It describes where declared storage is concentrated and does not measure compression quality, query speed, or file health. No curve is available when total rows or total column-chunk bytes are zero.

Technical Details:

Parquet separates the description of stored data from the pages containing values. That separation supports metadata-first reading and makes it possible to retrieve selected columns, while also explaining why metadata inspection and value decoding have different failure points.

Decoding Core

1. An ordinary unencrypted file begins and ends with PAR1. Immediately before the final marker, a four-byte little-endian length identifies the size of the preceding file metadata.
2. The metadata describes the schema, row groups, and column chunks. Row counts locate the groups intersecting a requested row window; byte offsets locate the required chunks. Declared offsets and lengths must remain inside the file's data region.
3. A column chunk contains page headers and page data. Decoding uses the page's encoding and the chunk's compression codec, reading dictionary values when required and checking that encoded counts and lengths fit the data.
4. Definition levels describe missing values so present values can be placed back into the correct rows. Repetition levels describe repeated fields in nested data. Reconstructing selected columns aligns their values by row before the requested window is returned.

A small row window can require complete pages and dictionary data. Selected column chunks in overlapping row groups may be read in full even though only a few rows are returned. Limiting output rows therefore does not guarantee an equally small read or decoded payload.

Dictionary encoding stores a list of values and encodes references to that list in data pages. Plain and dictionary-encoded pages can occur within one chunk, so a chunk's encoding list need not describe a single encoding used throughout. Run-length encoding represents repeated values compactly. Compression operates on encoded page data, and UNCOMPRESSED means that no compression codec is applied; it does not mean that the values have no encoding.

Preview compatibility

Preview is deliberately restricted to a flat schema with unambiguous column names. Required and optional primitive fields are eligible; repeated fields are not. Any nested structure in the schema prevents preview, including otherwise simple fields alongside it. The type rules are narrower than the complete Parquet specification.

Every row group for a selected column must declare UNCOMPRESSED or SNAPPY, including groups outside the requested window. An unsupported codec on an unselected column does not by itself prevent eligible flat columns from being previewed. Actual pages must also use a supported encoding compatible with their physical type. A recognized codec alone does not guarantee that a page can be read. Version 1 data pages using DELTA_BYTE_ARRAY are not previewed.

Encrypted data and column chunks stored in external files are outside the accepted input. Metadata inspection also checks footer bounds, schema structure, column locations, and agreement between the file's declared row count and the sum of its row-group counts. These checks establish the conditions for this inspection; they do not provide universal format validation.

Storage-share formulas

The storage curve uses declared compressed column-chunk sizes, including page headers. Its byte total excludes the footer and any bytes outside the reported column chunks. Uncompressed size describes encoded pages before compression, not the original CSV size or the memory needed to hold decoded rows.

Let R be the file's declared row count and B the sum of compressed column-chunk bytes across all row groups. At boundary k, R_k and B_k are the corresponding cumulative totals in file order. The percentage coordinates are truncated to four decimal places as follows.

The floor brackets discard the fractional remainder. Each percentage therefore has a resolution of 0.0001 percentage point without rounding the underlying integer counts. The horizontal coordinate is row share and the vertical coordinate is byte share. Two groups with three rows each and 100 versus 300 compressed bytes produce a first boundary at 50% of rows and 25% of bytes, followed by 100% on both axes.

Processing limits

These bounds apply to accepted files and selected decoding work. One MiB is 1,048,576 bytes. Maximum values are inclusive.

Some string encodings rebuild a value from a prefix of the preceding value and a new suffix. Those copied reconstructions share the 32 MiB allowance with decoded pages. This is a payload budget, not a hard cap on total browser memory. Requesting fewer rows may still encounter the same oversized page; fewer columns or another row window may reduce the work, but larger pages require another suitable reader.

A watchdog is set to stop an operation after seven seconds. Browser scheduling and shutdown can delay when cancellation is requested or observed, so seven seconds is not a universal exact completion deadline.

Privacy Notes:

The chosen file is read in local slices and processed in your browser. Its contents are not uploaded for inspection, and there is no remote-file input or server processing fallback. File contents, selections, and results are not placed in a shareable URL or saved as an inspection history in persistent browser storage.

Ordinary page resources and chart resources can still load over the network. Local file processing therefore does not mean that the entire page makes no network requests or is guaranteed to work without a connection.

Cancel stops active work and removes its preview while retaining metadata already read. Clear removes the selected file and inspection results from the page. Copied data and downloaded files remain under your control; clearing the inspection does not erase the clipboard, delete downloads, or change the original Parquet file.

Worked Examples:

References:

• Concepts, Apache Parquet.
• File Format, Apache Parquet.
• Logical Types, Apache Parquet.
• Encodings, Apache Parquet.
• Compression, Apache Parquet.
• Nested Encoding, Apache Parquet.
• Nulls, Apache Parquet.
• Parquet format metadata (parquet.thrift), Apache Software Foundation.
• How to read and write Parquet files with pandas, Simplified Guide.