Check a spreadsheet against your own rules

How it works

1. Drop a file
2. Pick your rules
3. Get the report

Your data stays on your machine

The file never leaves your browser. Everything runs locally — no upload, no server round-trip, no storage.

Passing every rule means only that nothing the rules looked for is wrong. You define what matters for your file. The checker reports what matches and what does not.

Built for files that are too important to get wrong:

• Payroll files - hours stored as text, pay codes that vary between rows, employee IDs that repeat.
• Employee lists - missing emails, inconsistent status labels, and duplicate IDs before the list reaches HR or provisioning.
• Price lists - SKU columns named differently, currency values mixed, prices outside the allowed range.
• Timesheets - work dates in the wrong format, hours stored as text, activity codes that do not match the allowed list.
• Customer import files - missing email columns, duplicate customer IDs, or inconsistent country codes.

The seven kinds of rule

Every check on this site is built from these. A rule set is just a list of them, saved against the column names in your own file, so the same set can be re-run on next week’s export without setting anything up again.

Required

The column must exist and every data row must have something in it. This is the rule that catches an export where a header was renamed, because a missing column fails every row at once rather than looking like scattered blanks.

Unique

No value may appear twice in the column, optionally ignoring capitalisation. Duplicate identifiers are the failure that survives a visual scan longest - a file of four thousand rows looks fine, and the two rows that matter are eight hundred apart.

Numeric range

The value has to be a number, and within the bounds you set. It catches two different problems with one rule: hours of 400 in a weekly file, and hours stored as text, which fails because a range cannot be compared against a string.

Date range

The value has to parse as a date and fall inside a window. Most of what this catches is not a wild date but a format mismatch - a US month-day export read as day-month, which turns 03/07 into a different day without ever looking wrong.

Allowed values

The value must be one of a list you supply, optionally ignoring capitalisation. Use it for status columns, pay codes, categories and anything else where a downstream system will only accept a fixed vocabulary.

Pattern

The value must match a regular expression. This is the rule for identifiers with a shape - an SKU that is three letters and four digits, a reference that always starts with the same prefix - where "not empty" is not a strong enough check.

Row count

The sheet as a whole must have at least, at most, or exactly a number of data rows. It is the guard against the empty export: a file that produced no rows passes every column rule there is, because there is nothing in it to fail.

What it will and will not read

CSV, TSV, plain text and XLSX. The first row is treated as the header, and everything below it as data - so totals rows, blank spacer rows and repeated headers are all read as records, and will fail row-level rules exactly like real rows do. Delete them before checking, or expect them in the report.

Up to 200,000 rows are read from a file. Larger files are truncated rather than refused, and the report says so, because a partial answer on a very large export is more useful than none - but a rule that passes on a truncated sheet has only passed on the part that was read.

A passing report means nothing the rules looked for is wrong. It is not a statement that the file is correct, and the checker has no opinion about whether your rules are the right ones. That judgement stays with the person who knows what the file is for.