Read the structure before the values
A Parquet file organizes data into row groups and column chunks. That layout lets a reader select useful columns without treating the file as a flat text document. The workbench first reads the footer and reports the declared rows, column schema and row-group sizes. Data-page checks happen when you request a scan.
A readable footer is not a guarantee that every column or page is valid. Start with the columns you need and inspect the result. The built-in example includes two row groups, large identifiers, exact decimals, nested values and nulls so you can see how the workflow behaves before choosing a private file.
Give every filter an explicit scope
The first-row field is zero-based: row 0 is the first physical record. A scan count sets a bounded window beginning there. Filters run inside that window and the result shows both scanned and matched rows. If you inspect 1,000 rows from a much larger file, an empty result means no match in those 1,000 rows, not proof that the value is absent everywhere.
Use the row-group shortcut when you want to inspect a particular physical partition. It fills the starting row and a bounded count; review those numbers before running. Row groups are storage boundaries and do not necessarily correspond to business partitions, dates or categories. The tool does not infer those meanings from position.
Understand the decode budget
Compressed file size alone does not tell you the amount of work needed. A selected group can hold a large dictionary, many repeated values or more decoded bytes than a small preview suggests. The reader checks its declared column and page sizes and applies separate limits to selected groups, values and output cells.
If a scan is refused, select fewer columns or a different row group. Reducing the visible row count may not fix an oversized dictionary or nested chunk. This release provides a bounded local inspection workflow; it does not promise arbitrary-size streaming, multi-file joins or cloud storage querying.