Log Format Validator

Every log pipeline has a contract: the shape each line is supposed to take so the next tool down the line can parse it. When a line breaks that contract — a mangled exporter, an extra field, a missing timestamp, a stray unescaped character in a JSON blob — downstream parsers silently drop the line, mis-slice a field, or corrupt an aggregate without ever raising an error. Log Format Validator checks a log against the format the system is supposed to emit and shows every line that does not comply, with its line number, so the offenders are trivial to locate instead of hiding somewhere in a wall of text.

Built-in presets cover the shapes seen most often in practice: a standard timestamp-and-level line, Apache/nginx combined access log format, syslog-style RFC 3164 entries, and structured JSON where each line must parse as its own valid object. A custom mode drops the presets entirely and validates every line against any regular expression supplied, anchored or not, for formats the presets do not cover. Each non-empty line is measured independently against the chosen contract — in JSON mode by attempting to parse it, in every other mode by requiring the pattern to match the entire line, not just a substring somewhere inside it — and the pass, fail, and pass-rate numbers reported in the summary always add up to exactly the lines shown as failing in the detail list below them.

Blank lines are treated as formatting, not data: they are skipped entirely rather than counted as either a pass or a failure, so a log with occasional blank separators between entries does not have its pass rate artificially dragged down by lines that were never meant to carry content in the first place.

• Preset formats — standard timestamp-and-level lines, Apache/nginx combined access logs, syslog RFC 3164 style, and structured JSON.
• Custom regex mode — validate against any log contract by supplying a regular expression directly, for formats none of the presets cover.
• Whole-line matching — in pattern mode a line only passes when the pattern matches it from end to end, so a partial or substring match is correctly reported as a failure.
• JSON parsing check — in JSON mode each line must parse as a standalone valid JSON value; malformed lines are reported with the actual JSON parser error message.
• Clear pass/fail report — summary counts for total, valid, and invalid lines, plus every failing line listed with its original line number and the reason it failed.
• Empty-line tolerance — blank lines are skipped entirely rather than being counted as failures, so separator lines never distort the pass rate.
• Pass rate summary — a single percentage that reflects exactly the valid-versus-total counts shown alongside it.
• Copy or download the list of failing lines for a fix-up pass or a ticket.
• 100% local — nothing leaves the browser, no upload, no server round trip.

1. Paste your log into the text box, or click Load sample to see a small worked example against the standard preset.
2. Pick a format preset from the dropdown — standard, Apache/nginx, syslog, or JSON — or choose Custom and type or paste a regular expression into the pattern box.
3. Click Validate format. Every non-empty line is checked against the chosen contract in one pass.
4. Read the summary cards — total lines, how many passed, how many failed, and the pass rate as a percentage.
5. Review the failing-lines panel — each entry shows the original line number, the offending line itself, and why it failed, whether that is “does not fully match the pattern” or a JSON parse error.
6. Export the failing lines with Copy or Download report to hand off for a fix.

Example 1 — Onboarding a new exporter. A partner system ships logs in a format that is almost, but not quite, standard. Validating against the standard preset instantly shows the handful of lines that would choke a parser expecting a strict timestamp and level.

Example 2 — Post-migration QA. After moving log shipping to a new pipeline, a day of fresh output is validated against the documented format; a 100% pass rate confirms nothing regressed, and anything less points straight at the lines that changed shape.

Example 3 — Vendor format check. An appliance exports logs in a peculiar, undocumented shape. A custom regular expression is built to match it, validating every record before it reaches a SIEM that would otherwise choke silently on the odd ones.

• Enforce format contracts — find every contract break instantly instead of discovering it downstream as a parser failure.
• Pre-built presets — validate the most common log shapes with no regex knowledge required.
• Custom mode — any format, any stack, by supplying the exact pattern the format is supposed to satisfy.
• Actionable report — line numbers and failure reasons lead straight to the problem, not just a raw pass/fail count.
• Numbers that add up — the summary counts and the detailed failure list are always computed from the same pass, so they never disagree.
• Private — all validation happens locally in the browser; the log is never transmitted.