Log Truncator

Logs do not read themselves, and worse, they do not always fit. Modern applications happily emit single lines that stretch to hundreds of kilobytes: a stack trace that forgot a newline, a serialized request or response body dumped in full, or one massive JSON record that never breaks. Those lines overflow database columns, wrap and split in terminals, break log shipper line limits and make every viewer that follows them choke, wrap, or silently truncate anyway — but now in a way you do not control and cannot reason about.

Log Truncator puts you in control of that cut. Paste any log, set the maximum line length you need to satisfy (120 columns for a terminal, 4096 bytes for a shipper, whatever your downstream system demands), and every line longer than the limit is trimmed to fit with an explicit marker — an ellipsis by default — so it is always obvious something was removed. When you also enable Keep words whole, the cut slides back to the nearest space, protecting identifiers, paths, and tokens from being sliced in half. The tool reports how many lines were changed and which line was the longest, so you can see both the scope of the problem and whether the result actually fits.

There is always a tension between fidelity and fit. The original text remains in the input above until you clear it, so truncation here is a deliberate, reversible view. This is for producing compact, well-behaved logs that land cleanly in the next system down the pipeline rather than a lossless transform.

The four summary cards give a quick read on the whole file: total lines, how many were actually truncated, the length of the single longest original line, and the resulting output size measured in real UTF-8 bytes rather than raw character count — so a log with accented names, emoji, or non-Latin scripts reports an accurate size against a byte-based downstream limit instead of silently under-counting multi-byte characters. That distinction matters: 100 East Asian characters is 100 characters long but roughly 300 bytes in UTF-8, and a shipper enforcing a byte ceiling will reject it long before a character count alone would flag it as too long.

• Configurable length limit — set any maximum line length in characters.
• Truncation marker — an appendable suffix (default ...) so trimmed lines are obvious.
• Keep words whole — break at the previous space to avoid splitting identifiers and paths.
• Hard fallback — a single over-long token is still forced to fit the limit.
• Line stats — total lines, truncated count, longest original line, and output size in real UTF-8 bytes.
• Whole-line safety — truncation only shortens the tail of a matched line; it never merges, drops, or reorders lines.
• Copy / Download TXT / Print — take the truncated view with you.
• 100% local — no upload, no network.

1. Paste your log — one entry per line. Lines longer than the limit are the targets for truncation.
2. Set the maximum length your downstream system requires, for example 4096 characters for a shipper, or 120 for a terminal.
3. Choose a marker or leave the default ellipsis; leave it empty for a strict hard cut.
4. Keep words whole if line breaks should land on spaces.
5. Run and read the summary cards, including the byte-accurate output size for byte-based limits.
6. Inspect and ship. Copy the preview or download it as text.

Example 1 — A shipper line limit. An application emits one JSON record per line but a rare exception serializes a 2 MB stack trace into a single line, blowing past a 4096-byte ingestion limit. Set Max line length to 4096, run, and the outlier line is trimmed to fit while ordinary records pass through unchanged.

Example 2 — terminal width. Your service logs full URLs including a query string, and the lines are 300 characters long, wrapping badly in an 80-column terminal. Set the limit to 80 with Keep words whole on and a marker of ..., and each URL is cut cleanly at the last space before the wrap point.

Example 3 — a strict cut. Some parsers treat a trailing ellipsis as payload; clear the marker so each over-length line is sliced with no suffix added.

Example 4 — multi-byte content. A log of user comments includes names and text in Japanese, Arabic, and emoji. A 4096-character cap looks generous, but the same content can run well past 4096 UTF-8 bytes; reading the output bytes card instead of the character count confirms the result actually clears a byte-based shipper limit.

• Fits the next system — stop getting rejected at shipper, database, or terminal boundaries.
• No surprises — explicit markers make every trim visible.
• Safe identifiers when Keep words whole is on.
• Quick sizing signal from the longest-line stat and the byte-accurate output size.
• Whole lines preserved — the line count never changes, only individual line lengths.
• Private — all processing stays local.