The first time this bit me, I was copying a block of terms and conditions out of a PDF into a support reply. It looked fine in the PDF. The moment it landed in my editor it turned into a staircase, every line snapping to a new row halfway across the page, because the PDF had baked a hard return into the end of every visual line. Fixing it by hand meant deleting a newline, adding a space, and repeating that forty times. I have built enough tools on toolz.dev to know when a job is worth automating, and this one had been quietly wasting my time for years. So I built the remove line breaks tool, and this guide is everything I learned about why the problem exists and how to clean it properly.
TL;DR: Text copied from PDFs, emails, and terminals often has a line break at the end of every display line instead of only at the end of each paragraph. Pasting it leaves broken, ragged lines. The remove line breaks tool deletes those newlines and joins the text with a separator you choose, and its paragraph-aware mode keeps the blank lines between paragraphs so the result reads as prose, not one giant run-on line. It all runs in your browser, so nothing is uploaded.
Why is my copied text full of line breaks?
The short answer is that a line break and a paragraph break are two different things, and a lot of software confuses them.
When you type in a word processor or a browser, you press Enter only at the end of a paragraph. The text wraps automatically inside the paragraph, so the visual lines you see are decided on the fly by the width of the window. There are no line break characters inside the paragraph at all. That is called soft wrapping, and it is why the same paragraph reflows cleanly when you resize the window.
A lot of other sources do the opposite. A PDF stores the position of every line, so when you copy text out of it, the extractor often puts a real newline character at the end of each line it sees on the page. Plain-text emails were historically wrapped at 72 or 76 columns with a hard return on every line, a convention that predates the web and still shows up in mailing lists and quoted replies. Code comments, log files, and anything printed to a fixed-width terminal do the same. In all of these, the newline is not marking the end of a thought, it is marking the end of a physical line that happened to be that wide.
When you paste that into a place that does soft wrapping, the two ideas collide. Your editor already wraps the text to fit, and now there are extra hard returns cutting the lines short before they reach the edge. The result is the staircase: lines that break at odd places, refuse to reflow, and look broken in every window size except the one they were copied from.
What does removing line breaks do?
Removing line breaks means deleting those newline characters and stitching the pieces back together so the words flow as continuous text again. The only real decision is what to put in the gap where each newline used to be.
Most of the time you want a single space, because the newline was standing in for the space between two words that a sentence would normally have. Sometimes you want nothing at all, for example when a long number or a code token was split across two lines and needs to be rejoined with no gap. And sometimes you want a comma or another separator, because the lines were really a list and you want them on one row as comma-separated values. The tool gives you all of these, plus a custom field for anything else.
There is one more character worth knowing about. Windows ends lines with two characters, a carriage return followed by a line feed, written as CRLF. Unix and modern macOS use a single line feed, LF. Very old Mac software used a lone carriage return, CR. If you mix text from different sources you can end up with a ragged combination of all three, and a naive find-and-replace that only looks for one of them leaves the others behind. The remove line breaks tool normalises all three first, so it does not matter where your text came from, every line ending is handled the same way.
How do I remove line breaks but keep my paragraphs?
This is the feature that turns the tool from a blunt instrument into a useful one, so it is worth understanding.
If you simply delete every newline in a document, you get one enormous paragraph. All the sentences run together into a single unbroken line, and the structure that made the text readable is gone. That is occasionally what you want, but usually it is not. What you want is to remove the accidental line breaks inside each paragraph while keeping the deliberate breaks between paragraphs.
The tool distinguishes the two by looking at blank lines. A single newline is treated as an accidental break inside a paragraph and gets removed. A blank line, which is two newlines in a row, is treated as a real paragraph boundary and is kept. So a document that was broken like this:
The quick brown fox
jumps over the lazy dog.
A second paragraph
follows after a blank line.
comes out as two clean paragraphs with a blank line between them, rather than one long line. This is exactly the shape of text copied from a PDF or a wrapped email, where each paragraph is internally broken but the paragraphs are separated by a blank line. Leave the keep-paragraph-breaks option on, which is the default, and the tool does the right thing without any further fiddling.
When you genuinely want everything on one line, turn that option off. Every newline in the whole input is then replaced by your chosen separator, which is how you turn a column of values into a single comma-separated row.
Which separator should I choose?
The separator is the string that replaces each removed line break. The right choice depends on what the lines represent. Here is how the common options behave on the same three-line input apple, banana, cherry:
| Separator | Result | Use it when |
|---|---|---|
| Space | apple banana cherry |
The lines are words or sentence fragments that should read as prose |
| Nothing | applebananacherry |
A single token was split across lines and must rejoin with no gap |
| Comma | apple, banana, cherry |
The lines are a list you want as comma-separated values |
| Semicolon | apple; banana; cherry |
You need a list separator that will not clash with commas in the data |
| Pipe | apple | banana | cherry |
You are building a Markdown table row or a delimited record |
| Custom | Whatever you type | You need a specific joiner such as - or a tab |
Space is the default because it is right far more often than any other choice for ordinary prose. The list separators come into their own when you are reshaping data rather than reading it, for instance turning a copied column out of a spreadsheet into a single row you can paste into a query.
What do the clean-up options do?
Two extra toggles tidy the output beyond the join itself, and both are on by default because they almost always help.
Trim removes the whitespace at the start and end of each line before the lines are joined. This matters because copied text frequently carries trailing spaces you cannot see, and indentation at the start of a line that you do not want to keep once the line is no longer its own line. Without trimming, those stray spaces survive the join and show up as awkward gaps in the middle of the joined text.
Collapse spaces goes one step further and reduces any run of two or more spaces or tabs down to a single space. Once lines are joined, it is easy to end up with double spaces where a trailing space met a leading space, or where the original text used spaces to align something. Collapsing them gives you the single spacing that prose expects. Importantly, this only touches spaces and tabs, never the newlines that separate your paragraphs, so it does not undo the paragraph-aware joining.
There is also a remove-empty-lines option, off by default, for the case where the input has stray blank lines you do not want to become paragraph gaps. With it on, empty lines are dropped rather than preserved, which is useful for cleaning up double-spaced exports.
Is doing this in the browser safe?
Yes, and this is a point I care about because it is the whole design philosophy behind toolz.dev. The remove line breaks tool runs entirely in your browser using JavaScript. The text you paste is processed in the memory of the page you are looking at, and it is never uploaded to a server. There is no account, no logging, and no network request carrying your content anywhere.
That matters more than it first appears. The text people most often need to reflow is text they copied from somewhere private: a contract out of a PDF, an internal email, a customer message, a block of code. Sending that to a remote server to have its newlines removed would be an absurd privacy trade for such a trivial operation. Because the work is local, there is no upload limit either, so a very large document reflows as fast as a short one, and the tool keeps working even if your connection drops after the page has loaded. If you want the longer argument for why client-side processing is the right default for utilities like this, I wrote it up in the data privacy and online tools guide.
How is this different from find and replace?
You can, of course, do this yourself in any editor with find and replace, and for a one-off it is fine. The reason I still reach for the dedicated tool comes down to the three things a manual find-and-replace gets wrong.
First, the paragraph problem. A plain replace of newline with space flattens everything into one line, because it cannot tell an in-paragraph break from a paragraph boundary. To preserve paragraphs by hand you have to do a two-step dance: first replace the double newline with a placeholder, then replace single newlines with spaces, then put the double newlines back. That is fiddly and easy to get wrong.
Second, the mixed line endings. If your text has a blend of CRLF, LF, and CR, a single find-and-replace pattern misses some of them, and you are left hunting for the stragglers. The tool normalises all three up front.
Third, the whitespace clean-up. After joining, you usually want to collapse the double spaces and trim the ends, which is one or two more replace passes done in the right order. The tool folds all of that into a single operation with visible toggles, so you can see exactly what each one does and adjust without redoing the whole thing.
None of this is impossible by hand. It is just slow and error-prone enough that a purpose-built tool pays for itself the second or third time you need it. The same logic is why I keep a whole shelf of small text utilities, like the duplicate line remover for deduping a list and the line sorter for ordering one, rather than reaching for a scratch script each time.
When would I want to remove all line breaks?
There are genuine cases for collapsing everything to a single line, and they are worth calling out so you know when to turn the paragraph option off.
The clearest one is data reshaping. You copy a single column out of a spreadsheet and it arrives as one value per line. You want it as a comma-separated list to drop into a SQL IN (...) clause or a config array. Turn off keep-paragraph-breaks, choose the comma separator, and you have your row. The same applies to building a Markdown table row with the pipe separator, or assembling a query string.
Another is rejoining a token that was wrapped. A long URL, a base64 blob, or an API key that got split across lines in an email needs to become one continuous string with no separator. Turn off paragraph breaks, choose nothing as the separator, and the fragments fuse back into a single token.
The rule of thumb is simple. If you are cleaning prose for a human to read, keep paragraphs on. If you are reshaping the text into a single machine-readable value, turn them off. Being able to flip between the two on the same input, watching the result update as you go, is the reason I built both behaviours into one tool rather than two. And if the cleaned text is headed somewhere you will keep editing, the broader kit on the site, from the case converter to the word counter, picks up where this one leaves off. For the wider set of everyday text and code helpers, the developer productivity tools guide is a good map, and the coding tools guide covers the formatting side.
Frequently asked questions
How do I remove line breaks from text?
Paste your text into the remove line breaks tool and keep the default settings. It replaces every line break inside a paragraph with a single space and shows the joined result instantly, which you can then copy. The whole thing happens in your browser.
How do I keep my paragraphs when removing line breaks?
Leave the keep-paragraph-breaks option on, which is the default. The tool then only flattens the single line breaks inside each paragraph and keeps one blank line between paragraphs, so the structure of the text is preserved instead of collapsing into one line.
Can I join all the lines into a single line?
Yes. Turn off the keep-paragraph-breaks option and the entire input is collapsed into one continuous line, which is handy for turning a column of values into a single comma-separated row or rejoining a token that was split across lines.
What is the difference between a line break and a carriage return?
A line break is the newline character used on Unix and modern Mac systems. A carriage return is the older Mac ending, and Windows uses both together as CRLF. The tool normalises all three, so any source text joins the same way regardless of where it came from.
How do I replace line breaks with a comma instead of a space?
Choose the comma separator. Each removed line break is replaced with a comma and a space, which turns a list of lines into a comma-separated list. A custom option lets you use any joiner you want, such as a tab or a dash.
Why does the output still have double spaces?
That happens when lines already ended in spaces before being joined. Turn on the collapse-spaces option to reduce any run of spaces or tabs to a single space, and turn on trim to remove the spaces at the ends of lines first. Both are on by default.
Does removing line breaks change the words in my text?
No. The tool only removes the newline characters and, if you ask, tidies whitespace. The words, punctuation, and their order are left exactly as they were, so the meaning of the text is unchanged.
Is it safe to paste private text here?
Yes. All processing happens entirely in your browser with JavaScript. Your text is never uploaded or stored, and the tool keeps working with no network connection once the page has loaded, which makes it safe for contracts, emails, and code.
