Remove Trailing Whitespace from Text

Where trailing whitespace comes from

The most common source is a text editor that inserts a space when you press the end-of-line key, or that fails to clean up after an auto-complete suggestion is dismissed. When you type a closing brace in a JavaScript file, accept a snippet, and then press Enter, some editors leave a ghost space on the line you just left. Multiply that across hundreds of saves and you accumulate dozens of invisible trailing characters that only appear when you run cat -A or enable "render whitespace" in your editor.

Copy-paste is the second major source. When you select a block of text in a browser, PDF reader, or word processor, the selection often extends slightly past the last visible character and picks up trailing spaces that were used for layout padding. The spaces are invisible in the destination editor but will show up in a diff the next time you commit. Pasting formatted content from Microsoft Word is especially likely to bring trailing spaces along, because Word internally pads paragraphs with spaces to aid its own layout engine.

Code generation tools — including language models — frequently emit trailing whitespace. A model generating Python or YAML may produce a line like key: value with spaces after the value because the sampling process does not track the "end of meaningful content" boundary. Running generated code through this tool before pasting it into a file avoids spurious diff noise when a human later edits that file and their editor auto-trims.

Trailing whitespace in specific file types

Markdown is unusual: two trailing spaces at the end of a line are intentional syntax — they force a line break (<br>) in the rendered output. This tool removes all trailing spaces, which will convert those intentional breaks into ordinary paragraph flow. If your Markdown uses double-space line breaks, use a more targeted editor command that skips lines with exactly two trailing spaces, or switch to the backslash line-break syntax ( \ at end of line) which is unambiguous and immune to whitespace stripping.

Python is strict about indentation but does not care about trailing whitespace on a line that has content. What it does care about is mixed tabs and spaces for indentation. If your file has a mix of tab-indented and space-indented lines, removing trailing tabs (which this tool does on each line's right side) does not fix the indentation issue — the problem is on the left side of each line, not the right. Use a dedicated indentation normaliser for that.

YAML parsers vary. Most tolerate trailing spaces in scalar values, but block scalars (the literal | and folded > styles) include trailing whitespace in the parsed string content. If a YAML value is a multiline block scalar and you strip trailing spaces from it, the value seen by the parser will change. That is usually the desired outcome when the trailing spaces were accidental, but worth knowing if the YAML was generated deliberately with padding.

CSV fields that contain a quoted string — for example "Smith ",25 — have their trailing spaces inside the quotes, not outside them. Those spaces are part of the field value and are stripped by this tool because the closing quote is still the last non-whitespace character on the line. Whether that is correct depends on your data: a name field probably does not need the trailing spaces, but a fixed-width text field that was padded to a known length deliberately might. Inspect before bulk-cleaning CSV.

How this differs from collapsing multiple spaces

Trailing whitespace removal operates only on the right end of each line. It does not touch spaces that appear inside a line — between words, inside function arguments, or after punctuation. If you have a line like hello world , this tool produces hello world— three internal spaces preserved, three trailing spaces gone.

If you want to collapse internal runs of multiple spaces into a single space, that is a different operation. Use a remove extra spaces tool for that. The two operations are often combined in a cleaning pipeline: first collapse internal whitespace, then strip trailing whitespace, then normalise newlines. Doing them in that order avoids a situation where collapsing creates a new single trailing space that then needs another pass to remove.

Leading whitespace — indentation — is also untouched. Code indentation, quoted-block indentation in Markdown, and YAML structure all depend on the spaces and tabs at the start of a line. A tool that strips those would break the structure of any indented file. This tool is safe to run on code because it only affects the invisible characters after your content ends, not the characters before it begins.

Trailing whitespace and version control

In Git, every character counts toward the SHA of a commit. A line ending in three spaces has a different hash than the same line without them, which means a commit that only removes trailing whitespace is a real diff — it changes the file content. Whether that diff is visible depends on your diff tool: Git's default diff renderer highlights trailing whitespace in red in some terminal configurations, but other tools silently show the lines as identical. The result is reviewers approving changes that include invisible modifications, or CI pipelines failing on a linter check that no one can see in the PR view.

The conventional solution is to enforce trailing-whitespace cleanliness at the commit stage with a pre-commit hook. A minimal .pre-commit-config.yaml entry looks like:

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: trailing-whitespace

This hook runs before every commit and fails if any staged file contains trailing whitespace, forcing the developer to clean up before the commit goes through. When onboarding an existing codebase that has accumulated years of trailing whitespace, it is usually better to make one dedicated "clean trailing whitespace" commit across all files before enabling the hook, so that future diffs are not polluted by the cleanup and the blame history stays readable.

Removing trailing whitespace with common tools

sed on Unix/macOS:

sed 's/[[:space:]]*$//' input.txt > output.txt

This uses POSIX character class [[:space:]] which matches both spaces and tabs. The *$ anchors to end-of-line and replaces the run with nothing.

Python one-liner for a file:

python3 -c "
import sys
for line in sys.stdin:
    print(line.rstrip())
" < input.txt > output.txt

str.rstrip() with no argument strips all trailing whitespace including spaces, tabs, carriage returns, and newlines. If you want to preserve Windows-style line endings (CRLF) and only strip spaces and tabs, use line.rstrip(" \t") instead.

Node.js for a string variable:

const cleaned = text
  .split("\n")
  .map(line => line.replace(/[ \t]+$/, ""))
  .join("\n");

The regex /[ \t]+$/ targets only spaces and tabs, leaving carriage returns intact. This is the same logic this tool uses in the browser.

Linters, .editorconfig, and enforcing clean lines across a team

The challenge with trailing whitespace is not fixing it once — it is keeping it fixed. Any developer who has not configured their editor to trim on save will re-introduce it silently. That is why most projects enforce the rule at the tooling level rather than relying on personal editor settings.

.editorconfig is the most portable option because virtually every modern editor reads it without a plugin. A minimal file at the project root looks like:

root = true

[*]
trim_trailing_whitespace = true
insert_final_newline = true

VS Code, JetBrains IDEs, Vim (with the editorconfig plugin), Sublime Text, and Emacs all respect this file. You can scope the rule per extension: [*.md] can set trim_trailing_whitespace = false if your Markdown source intentionally uses two-space hard line breaks, while [*.py] and [*.yaml] keep the rule on.

ESLint's no-trailing-spaces rule flags trailing whitespace during lint. In a flat-config file it takes one entry:

// eslint.config.js
export default [
  { rules: { "no-trailing-spaces": "error" } },
];

By default it also flags trailing spaces on blank lines. Pass { "skipBlankLines": true } if that is too noisy. Prettier removes trailing whitespace automatically when it reformats a file, so projects using prettier --check . in CI do not need the ESLint rule separately.

git diff --check is a lightweight guard that needs no external tools:

git diff --check HEAD

Git marks any line that introduces trailing whitespace with a warning and exits non-zero, making it easy to drop into a pre-push hook. For a legacy codebase with years of accumulated trailing whitespace, the cleanest path is a single standalone commit — message: chore: strip trailing whitespace from all tracked files — then enable the hook in the same PR. Separating the cleanup commit from feature work keeps git blame readable: blame on any line still points to the last meaningful change, not to a housekeeping commit.

The Markdown two-space hard line break: when trailing spaces are intentional

Markdown is the one common format where trailing whitespace is part of the specification, not an accident. The original Markdown syntax defined that ending a line with two or more spaces forces a hard line break — a <br> in the rendered HTML. The CommonMark specification, which GitHub Flavored Markdown, Pandoc, and most modern parsers follow, preserves this behavior.

If you paste a Markdown document into this tool, two-space line breaks are silently removed and become soft breaks, flowing into the next line in the rendered output. A poem or address block formatted with two-space breaks will reflow into a single paragraph. For documents where line breaks matter, the backslash hard-break syntax is a safer alternative:

Line one\
Line two\
Line three

A backslash before the newline is recognized by CommonMark, GitHub, Pandoc, and Jekyll. It survives any trailing-whitespace stripper because it is a visible character. Two trailing spaces are invisible — which is exactly why editors and linters keep stripping them without asking.

If you are converting an existing Markdown document, a targeted find-and-replace is more precise than a blanket strip. In VS Code, open the file with View → Render Whitespace → All. Intentional two-space line breaks appear as exactly two gray dots at the end of a line. Scattered dots in varying counts are almost certainly accidental trailing whitespace from an editor or paste, not intentional syntax. Replace the intentional two-space breaks with backslashes first, then run a trailing-whitespace strip on the result. This way the operation is auditable in a diff: one change per intentional break, and a separate set of deletions for the accidental ones.

Some static-site generators treat two-space breaks and soft breaks identically in their Markdown parser configuration. Check by rendering a test snippet before running a bulk cleanup on a large content directory. If your generator ignores the two-space syntax, the distinction is moot and a blanket trailing-whitespace strip is safe.

Why pasted text from PDFs and chat apps carries trailing spaces

When trailing whitespace appears in text you did not type yourself, the source is almost always the way the originating application represented the text before you copied it.

PDF files do not store text as a stream of characters with newlines. They store individual glyphs with x/y coordinates on a page. When you select and copy a paragraph, the PDF reader reconstructs the text by sorting glyphs left-to-right and inferring line breaks from vertical gaps between rows. If the original document used full-width justification, the reader often pads short lines with spaces to bring them to the right-margin position in the reconstructed output. A paragraph copied from a two-column PDF can arrive with ten to fifteen trailing spaces per line, invisible until you paste into an editor with "render whitespace" enabled or run cat -A on the file.

Slack and Microsoft Teams render messages in a fixed-width container. When you select a message that wraps across multiple visual lines and copy it, the application sometimes includes a space at each visual-wrap point — the space that was the last character before the line wrapped in the chat window. This appears in the pasted text as a trailing space on every wrapped line, which can be many lines for a long message in a narrow sidebar.

Support platform exports from tools like Zendesk, Intercom, and Freshdesk often pad every line to a fixed column width — commonly 72 or 80 characters. A message shorter than the column width is padded with spaces to alignment. These padding spaces enter any database, log file, or version-controlled document they are pasted into, and produce misleading diff noise the first time a human edits the file and their editor trims trailing whitespace.

Web page selections can pick up trailing spaces from browser inline layout. An element styled with padding-right or letter-spacing can cause the browser's text-selection engine to extend the selection slightly past the last visible character. This is more common with monospace code blocks than with prose text.

To check any file quickly: in a terminal, cat -A filename on Linux or cat -et filename on macOS appends a $ marker at each line ending, making any gap between the last visible character and the dollar sign immediately obvious. In VS Code, View → Render Whitespace → All shows trailing spaces as gray dots after the last character on each line.

How this tool differs from removing extra spaces or removing line breaks

Three whitespace operations get conflated because they all involve "cleaning up spaces," but they target completely different characters at completely different positions in the text.

Trailing whitespace removal (this tool) looks at the right end of each line and deletes spaces and tabs that appear after the last non-whitespace character. It does not change any space inside a line, does not change indentation, and does not remove or merge any newlines. Input and output have the same number of lines, the same visible text, and the same structure. The only bytes that change are the invisible ones at the tail of each line.

Extra space removal targets runs of multiple consecutive spaces inside a line — between words, after punctuation, inside arguments. The line the quick brown fox becomes the quick brown fox. This is useful for prose typed with double spaces after periods, or text exported from a fixed-width column format where inter-word gaps were padded to alignment. The remove extra spaces from text tool handles this and does not touch line endings or trailing spaces.

Line break removal strips the newline characters between lines, merging a multiline block into a single continuous paragraph. This is the right operation when you copied text from a PDF that was reflowed into narrow columns: every line ends with a hard break even though the original text was flowing prose. The remove line breaks from text tool handles this without changing spacing inside lines.

When content needs all three operations — a narrow-column PDF export with inter-word padding and trailing spaces — the recommended order is: remove line breaks first to restore paragraph flow, then collapse extra spaces to fix the inter-word padding, then strip trailing whitespace from the result. Running extra-space removal before line-break removal can merge the last word of one line with the first word of the next if there was no space between them after the strip, producing run-together words. The order above avoids that. Each tool is scoped to exactly one operation so the combined result is predictable and each step can be inspected independently.