Mac data review checklist: prove the CSV survived

The short answer: accept a CSV or converted JSON file only after five checks agree. Record the source and import settings, verify the table shape, test meaning-sensitive values, compare the converted output, and save the readable review state. Row count alone is not enough.

This Mac data review checklist is for product exports, client lists, research tables, QA fixtures, spreadsheet handoffs, and small imports. It is not a database migration plan or a schema validator. The useful outcome is a compact acceptance record that another person can reproduce.

Disclosure: I build TeenyApps, including TeenyTool for local text and data utilities and TeenyDisplay for external monitor controls. My bias is toward small native Mac tools and local workflows. The baseline is still Finder, Numbers, Excel, Sheets, macOS Displays, and your source data.

What counts as CSV acceptance evidence?

01Freeze the source before opening the table

Save the original export in a named Finder folder and make a working copy before sorting, deleting columns, changing dates, or converting formats. Record the source app, account or environment, export time, active filter, file size, and raw filename. An export from "active customers" is not interchangeable with "all customers" even when both have the same columns.

Use filenames that state their role and date, such as 2026-08-03-support-export-raw.csv, 2026-08-03-support-export-reviewed.csv, and 2026-08-03-support-export.json. A reviewer should know which file is immutable and which file contains edits without opening either one.

Do not treat a modified time or a successful download as proof of completeness. Compare the export count shown by the source product, when available, with the data-row count you observe after parsing.

02Prove how the CSV parsed

CSV has no single enforced schema. RFC 4180 documents a common comma-separated format with an optional header, quoted fields, doubled quotes, and line breaks inside quoted fields. The W3C tabular-data model treats the dialect and table metadata as separate facts, which is a useful reminder: the bytes do not explain themselves.

Apple Numbers can adjust delimiter, text qualifier, text encoding, duplicate-delimiter handling, and row or column transposition for imported delimited text. Apple also notes that you cannot change those import settings after editing the imported table. Record the settings before making changes.

Use this parse pass:

1. Confirm the delimiter and whether row 1 is a header or data.
2. Confirm the text qualifier and encoding before editing.
3. Compare the header width with the parsed width of every row if your tool can report it.
4. Check that header names are present, unique, and meaningful to the destination.
5. Count data rows separately from the header and blank trailing lines.

Do not count commas by hand. A quoted field may contain a valid comma or line break. Use the parsed table or a real CSV parser, then inspect the rows that differ from the expected shape.

03Test values that can change meaning

A rectangular table can still be wrong. Choose rows that expose type and encoding risks: IDs with leading zeros, blank and missing values, dates, booleans, negative and decimal numbers, long notes, embedded commas, doubled quotes, line breaks, and non-ASCII names.

Write down the expected representation before conversion. For example, 00123 may be an identifier that must remain text, an empty field may differ from a true null, and 2026-08-03 may be a date string rather than a timestamp. The destination schema, not the source file's appearance, decides.

If the file will be imported into Contacts, Apple recommends checking that CSV fields use a consistent shape, the delimiter is correct, the encoding is appropriate, and the imported field labels map correctly. The destination-specific preview is part of acceptance because generic CSV checks cannot know the target field rules.

04Convert a copy and record the tool boundary

Use local conversion for private or unreleased data unless you have approved another data path. Local processing reduces exposure, but it does not prove correctness. The converter's parser and type rules still matter.

TeenyTool's CSV to JSON utility parses comma-delimited rows, quoted fields, doubled quotes, CRLF and LF line endings, and line breaks inside quotes. You can choose whether the first row is the header; without a header it creates col0, col1, and later keys. It outputs a JSON array and reports the converted object count.

The current source also shows important limits. CSV-to-JSON conversion automatically turns empty strings into nulls; recognizes true, false, yes, no, null, and nil; and then tries integer and decimal conversion. A short row gets empty values for missing header positions. Values beyond the header width are not added to the object. The utility does not ask for a different delimiter or validate a destination schema.

Those behaviors make a focused before-and-after check essential. Compare object count, key set, missing and empty fields, leading-zero IDs, numeric precision, quotes, line breaks, and non-ASCII text. Keep the output only when those values still match their intended meaning.

05Make the comparison readable

A larger display helps only when it exposes the evidence. Keep the raw source or parsed table, converted output, destination requirements, and review note visible without hiding field names or truncating the values you are checking. Use the built-in display for the note if the external monitor holds the wide table.

macOS owns display detection, arrangement, mirroring, and the main-display choice. TeenyDisplay's spreadsheet-review guide covers supported monitor controls and a repeatable Review preset. Its current source can save brightness, contrast, volume, input, resolution, refresh rate, and HiDPI state per matched display. The preset does not validate cells, formulas, or import settings.

Record the visible display mode or preset only when it affects reproducibility. If a clipped column or unreadable wrapped value could hide an error, fix the layout before accepting the file.

06Save a compact acceptance record

The handoff note should state what passed and what remains uncertain. Keep it beside the reviewed file instead of relying on memory.

A useful acceptance record includes:

1. Source app, account or environment, export time, and filter.
2. Raw and reviewed filenames.
3. Delimiter, qualifier, encoding, and header setting.
4. Data-row count, column count, and expected field names.
5. Meaning-sensitive values checked and their expected types.
6. Conversion tool, output filename, and before-and-after evidence.
7. Destination preview or sample-import result, when applicable.
8. Display state only when it matters to the review.
9. Known exceptions, owner, result, and next action.

If the accepted data becomes a dashboard screenshot or KPI packet, use the Mac dashboard QA checklist next. That page starts after the source file and conversion evidence have passed.

Ten-minute first-pass routine

1. Create one Finder folder for the data review.
2. Save the raw CSV or JSON file unchanged.
3. Make a working copy before editing or converting.
4. Record the source, environment, export time, and filter.
5. Set and record the delimiter, qualifier, encoding, and header choice.
6. Check data-row count, column count, and field names.
7. Sample rows with quotes, blanks, IDs, dates, long text, and non-ASCII characters.
8. Write down expected types for values that could be coerced.
9. Convert a working copy locally when the destination needs JSON.
10. Compare object count, key set, missing values, and sampled values.
11. Preview the destination mapping or run a safe sample import when available.
12. Use a display layout that exposes every compared field.
13. Save the result, exceptions, and next action in the acceptance record.

Sources checked

• TeenyTool claims and limits were checked against the TeenyTool homepage and current local Swift source for CSV parsing, header handling, automatic type coercion, short and wide rows, output shape, and row reporting.
• TeenyDisplay claims and limits were checked against the TeenyDisplay homepage and current local Swift source for display modes, refresh rates, HiDPI state, preset fields, display matching, DDC controls, and fallback behavior.
• RFC 4180: Common Format and MIME Type for Comma-Separated Values Files.
• RFC 8259: The JavaScript Object Notation Data Interchange Format.
• W3C: Model for Tabular Data and Metadata on the Web.
• Apple Support: Import an Excel or text file into Numbers on Mac.
• Apple Support: Import contacts into Contacts on Mac.
• Apple Support: Connect displays to your Mac.
• Apple Support: Displays settings on Mac.

FAQ

How do I validate a CSV before converting it to JSON on Mac?

Keep the raw file, record the delimiter, text qualifier, encoding, and header setting, then compare row count, column count, field names, empty values, and text-like IDs before and after conversion. Test rows with quotes, embedded commas, line breaks, and non-ASCII text.

Is opening a CSV in Numbers enough to validate it?

No. Numbers provides useful delimiter, text qualifier, and encoding controls, but a readable table does not prove that field names, row shape, empty values, dates, identifiers, and post-conversion types still match the source and destination requirements.

Should I use an external monitor for data review?

Use an external monitor when it keeps the source, parsed table, converted output, and review note readable at the same time. The monitor does not validate the data. It reduces window switching and makes side-by-side evidence easier to compare.