/validator

Validate a .ulc.json record.

Drop a file to check it against the ULC schema (JSON Schema Draft 2020-12). Add its source PDF, IES, or LDT and the validator verifies their SHA-256 hashes against the record, all in your browser.

Files never leave your browser.
Paste JSON instead
Try a sample record

Four canonical reference records. Pick one and the validator loads it as if you had dropped it yourself.

What this validator checks.

  1. Schema conformance

    Every required field is present and every value is the right type. Full schema validation, including that every enumerated value falls inside the closed taxonomy the spec defines, runs in the canonical Go CLI and is being wired into this in-browser check.

  2. Conformance level

    The validator computes a record's conformance level (core, standard, or full) from the data it actually carries. Core is the minimum identifying and photometric set, standard is what a typical LM-79 report produces, and full adds the comprehensive set. Because the level is computed and verified rather than self-declared, full means the data is genuinely present.

  3. JSON parse

    Malformed JSON is caught first, with the line and column, before schema checks run. Usual suspects: a trailing comma, an unescaped quote, a missing brace.

  4. Source-file hash verification

    Drop the PDF, IES, or LDT files the record declares in its source_files block and the validator recomputes their SHA-256 hashes in your browser, then checks them against the record.

What a hash match proves.

A ULC record claims that every value traces back to the manufacturer's own datasheet, IES, and LDT files. But a JSON file is just text: easy to copy, easy to edit. So how do you know the record matches the real source files, and that no one changed a lumen output or a CRI after the fact?

ULC doesn't embed the source files; it fingerprints them. Each declared source file carries a SHA-256 hash: a 64-character fingerprint computed from the file's exact bytes. The same file always produces the same fingerprint. Change a single byte, even one invisible character, and the fingerprint changes completely. You can't run it backward to recover the file, and you can't craft a different file that lands on the same fingerprint.

Drop the original PDF, IES, or LDT next to the record and the validator recomputes each fingerprint in your browser, then compares it to the one the record declares. A match means this is the exact file the record was built from, unchanged. A mismatch means the file and the record disagree, and you know not to trust the record's numbers. Anyone can run this check, with any SHA-256 tool, without trusting a server, the person who sent the file, or even this validator.

Match

Identical fingerprints. This is the exact file the record was built from, unchanged.

Mismatch

The fingerprints differ. The file and the record disagree; the numbers are not safe to trust.

The same one-way function, run on the same file at two different times. If the fingerprints agree, the bytes are identical. No server, and no trust, required.
How this validator compares to the Go CLI.

This in-browser validator runs a structural pre-check against the canonical JSON Schema. The Go CLI available from /downloads is the canonical reference implementation and runs the complete schema check today; both are tested in CI against the four canonical reference records.

For byte-exact validation, download the Go CLI: /downloads.

Learn more