Malformed Line Detector

Some log lines are wrong in ways a strict format check misses: a stray tab where spaces belong, a line that ends in whitespace, a blank slot in a file that should have none, a fragment of a record split across two writes. Malformed Line Detector sweeps a log for those corrupt lines and reports each one with its line number and the exact reason it was flagged.

Layering a configurable format pattern over a set of content heuristics, it does what an on-call engineer does when a file looks suspicious: check the shape, then check the bytes. Every detector — pattern mismatch, control characters, unusual whitespace, trailing spaces, empty lines — can be switched on or off individually, and the report separates flagged lines from clean ones so the noise never hides the signal.

The healthy-line pattern is the shape check: a regular expression every well-formed line should match in full, such as the default timestamp-prefixed pattern ^\d{4}-\d{2}-\d{2}[T ]\d{2}:\d{2}:\d{2}.*$. Swap in your own pattern for any log format, or leave the field empty to skip shape checking and rely on content heuristics alone. Those heuristics look past the shape and into the bytes: a control character (an unprintable byte other than a tab or newline) usually means the file was corrupted in transit; a run of two or more spaces, or any tab, signals a malformed separator; trailing whitespace is invisible in most viewers but can break exact-match parsers; and a blank line is flagged as its own category, since a one-record-per-line file rarely has a legitimate reason to contain an empty one.

• Pattern-mismatch detection — lines that fail your expected regex to match end-to-end, not just partially.
• Control-character scan — stray unprintable bytes (excluding ordinary tab and newline) that corrupt downstream parsing, reported with the exact Unicode code point.
• Unusual whitespace flags — any tab character or a run of two or more consecutive spaces.
• Trailing-whitespace check — invisible corruption at the end of a line that most editors hide from view.
• Empty-line detection — blank or whitespace-only lines, flagged as their own category rather than lumped in with content checks.
• Per-detector toggles — turn any single check off if it is too noisy for a particular file, without losing the others.
• Multiple reasons per line — a line with both a pattern mismatch and trailing whitespace shows both, so you see the full picture at a glance.
• 100% local — nothing leaves the browser, no upload, no server round trip.

1. Paste your log into the text box — any plain-text log works, structured or not.
2. Set the healthy-line pattern if your log has a predictable shape, or clear the field to skip shape checking and rely on content heuristics alone.
3. Toggle the checks you care about — pattern mismatch, control characters, unusual whitespace, trailing whitespace, and empty lines can each be switched independently.
4. Scan. Every line is checked against the active detectors and given a line number plus every reason it was flagged.
5. Read the summary cards — lines scanned, flagged count, clean count, and the flagging rate as a percentage.
6. Review flagged lines in the report, then copy or download it for triage or to hand to whoever owns the file.

Example 1 — Corrupt ingest file. A downstream parser keeps silently dropping records from an otherwise normal-looking log. Turning on the whitespace and trailing-space checks reveals that a subset of lines use tab separators where the rest of the file uses spaces, exactly the mismatch the parser chokes on.

Example 2 — Split-write fragments. A crashed writer process leaves a handful of partial lines mid-file, cut off mid-record with no trailing newline handled correctly. Lines that fail the healthy-line pattern are caught and listed by line number, ready for manual repair or exclusion before reprocessing.

Example 3 — Vendor file sanity check. Before loading a file delivered by an external partner into your pipeline, run it through the detector with a strict pattern matching your expected schema. Any flagged line — wrong shape, stray control byte, or unexpected blank — gets reviewed and either fixed or rejected before it ever reaches production.

Example 4 — Encoding mismatch. A log exported from a Windows tool occasionally embeds stray control bytes where a text editor inserted the wrong line-ending or encoding. The control-character check names the exact code point on each affected line, turning a vague “this file looks weird” into a precise, actionable list.

• Catches what a bare regex misses — content-level corruption like stray control bytes and whitespace that a shape check alone would pass.
• Instant triage — line numbers plus every reason, ready to hand off without re-reading the whole file.
• Tunable detectors — check exactly the failure modes you care about and mute the rest.
• Low noise — clean and flagged lines are reported separately with a clear percentage, so a handful of bad lines never gets lost in a big file.
• Works with or without a schema — content heuristics still run even if you have no format pattern to check against.
• Private — all processing stays local, in your browser.