DEV Community: xiu kuang

Building a Browser-Based Line Break Remover with Local-First Text Processing

xiu kuang — Sat, 01 Aug 2026 02:28:59 +0000

Removing line breaks looks like a one-regex job. text.replace(/\n/g, '') and you're done. Then real text shows up, and it turns out line endings are a small historical mess.

There are three different characters that can end a line: LF, CRLF, and CR. Text copied from Word, a spreadsheet, or a GitHub issue uses whichever one its origin platform chose, and a single paste can contain several at once. Remove only \n and the \r characters are still there. Remove everything and paragraph boundaries collapse into a wall of text.

I built a line break remover as part of TextFixHub, a collection of free browser-based text utilities.

You can try it here:

TextFixHub Line Break Remover

Three modes, because the task is three different things

"Remove line breaks" means something different depending on what the text is for:

Replace with space — single breaks become spaces; blank lines stay as paragraph breaks. The default, and the safest.
Remove entirely — every break is deleted. Words will run together. Useful when you know the input has no fragile spots.
Remove with space — every break is deleted, but a space is added where each line ended, so words don't glue together.

The first version had two modes. The gap showed up fast: paste Hello\nWorld, pick "Remove entirely", get HelloWorld. That's not what anyone wants, so a third mode exists now.

The pipeline

Strip the BOM if present.
Normalize all line endings to LF.
Apply the selected mode.
Remove trailing whitespace.

The BOM

Some files edited on Windows start with a byte-order mark (U+FEFF). It's invisible, but it is the first character, and it quietly breaks naive logic. One line handles it:

if (text.charCodeAt(0) === 0xfeff) {
  text = text.slice(1);
}

Line endings are a historical accident

Line ending	Bytes	Where it comes from
LF	`\n`	Unix, macOS, most web content
CRLF	`\r\n`	Windows
CR	`\r`	Classic Mac OS (rare now, but real)

Mixed endings appear in the same input more often than you'd expect. The fix is to normalize first, in the right order — CRLF has to be handled before CR, otherwise \r\n becomes \n\n and invents a phantom blank line:

const CRLF_RE = /\r\n/g;
const CR_RE = /\r/g;

text = text.replace(CRLF_RE, '\n').replace(CR_RE, '\n');

Protecting paragraph breaks

"Replace with space" should keep paragraphs. Two or more consecutive newlines are a paragraph boundary, so they need to survive while single breaks turn into spaces.

The trick is a placeholder. Swap the paragraph break for a character the input can't contain — NUL (\0) — handle the single breaks, then put the paragraphs back:

const withParaBreaks = text.replace(DOUBLE_NEWLINE_RE, '\0');
const withSpaces = withParaBreaks.replace(NEWLINE_RE, ' ');
const result = withSpaces.replace(/\0/g, '\n');

Three regex passes, no state machine, no index bookkeeping. The placeholder stays in my toolbox for any text transformation where some matches need to survive while others don't.

Why it stays in the browser

The input never leaves the device. No upload, no server-side API, no account. For a text tool, all of the work is local anyway, so the deployment stays static and the privacy story is easy to verify — the code that touches your text is right in the browser, not hidden behind an API.

Testing the edge cases

The behavior above stays correct only if the tests pin it down. The suite covers:

CRLF, LF, and CR endings individually
Mixed endings in one input (A\r\nB\nC\r → A B C)
Paragraph preservation with 2 and 3 consecutive breaks
Empty input and single-word input
Trailing newlines
The BOM case
Large inputs: 100K+ characters processed in well under 500ms

What I learned

"Remove line breaks" is not one operation. It's at least three, and the difference between them matters to the user even when the user can't name it. Hello\nWorld becoming HelloWorld is the perfect example — paste a list, pick the wrong mode, get garbage, and no error message explains why.

The placeholder trick generalizes: pick a character the input can't contain, and protecting part of a match while transforming the rest stops being scary.

The finished tool is here:

TextFixHub Line Break Remover

The other TextFixHub tools are at https://www.textfixhub.com/.

If you spot any mistakes here, please point them out — I'd appreciate it. Thanks for reading.

Building a Browser-Based Sentence Counter with Local-First Text Processing

xiu kuang — Fri, 31 Jul 2026 02:14:15 +0000

Many text utilities are simple enough to run entirely in the browser.

A sentence counter is a good example. The browser already has everything it needs to accept text, analyze it, and display useful statistics. Sending the input to a remote server is often unnecessary.

I built a small browser-based sentence counter as part of TextFixHub, a collection of free text utilities for everyday writing and editing.

You can try it here:

TextFixHub Sentence Counter

Why process text locally?

Text input can be sensitive. It may contain:

Draft articles
School assignments
Internal notes
Customer messages
Code comments
Unpublished content

For a basic counting tool, uploading this text to a server does not provide much additional value. Local processing has several useful properties:

The input does not need to leave the user's device.
There is no text-processing API to maintain.
The tool can respond without waiting for a network request.
The application can work without a user account.
The server does not need to store or process the submitted text.

This does not make every browser application private by default. Analytics, third-party scripts, error reporting, and hosting configuration still matter. It simply means that the core text analysis can remain local.

What the tool calculates

The sentence counter displays more than just a sentence total. It also calculates:

Sentence count
Word count
Character count with spaces
Character count without spaces
Paragraph count
Line count
Average sentence length
Average word length
Estimated reading time
Estimated speaking time

The additional statistics make the tool useful for editing and reviewing content, rather than only answering “How many sentences are there?”

A simple analysis pipeline

The browser-side pipeline is intentionally straightforward:

Read the current value from the text input.
Normalize the relevant whitespace.
Detect sentence boundaries.
Split the text into words, paragraphs, and lines.
Calculate the derived statistics.
Render the results immediately.

The important design choice is that the input stays in the browser throughout this process.

A simplified version of the idea looks like this:

type TextStats = {
  sentences: number
  words: number
  characters: number
  charactersWithoutSpaces: number
  paragraphs: number
  lines: number
}

function countWords(text: string): number {
  const normalized = text.trim()

  if (!normalized) {
    return 0
  }

  return normalized.split(/\s+/).length
}

function countCharactersWithoutSpaces(text: string): number {
  return text.replace(/\s/g, '').length
}

The actual implementation also needs to handle empty input, whitespace-only input, paragraph boundaries, and the distinction between visible characters and whitespace.

Sentence boundaries are not completely trivial

Counting sentences looks easy until real text appears.

A simple approach can count punctuation such as ., !, and ?. However, periods can also appear in:

Abbreviations
Decimal numbers
Domain names
Email addresses
Version numbers
Initials

This means that a sentence counter should not imply perfect linguistic understanding. It is a practical text utility with defined heuristics.

For a lightweight browser tool, a transparent heuristic is often more useful than a large natural-language-processing dependency. The tool should also explain what it counts and avoid presenting an approximate result as a scientific linguistic measurement.

Reading time and speaking time

Reading and speaking time are estimates based on word count.

For example, the application can use separate words-per-minute assumptions:

const READING_WORDS_PER_MINUTE = 200
const SPEAKING_WORDS_PER_MINUTE = 130

const readingMinutes =
  wordCount / READING_WORDS_PER_MINUTE

const speakingMinutes =
  wordCount / SPEAKING_WORDS_PER_MINUTE

These numbers are not universal facts about every reader or speaker. They are simple reference estimates that help users understand the approximate size of their text.

The interface should avoid suggesting false precision. Displaying “about 2 minutes” is generally more useful than displaying a value with several decimal places.

Why I used a static deployment

The application is built with Next.js and TypeScript and deployed as a static website.

The tool does not need a database or an application server to analyze text. This keeps the architecture small:

The UI runs in the browser.
The text-processing functions are regular TypeScript modules.
The page can be statically generated.
The deployment surface is smaller than a server-based implementation.

A smaller architecture also makes the privacy explanation easier to verify: the main text operation is visible in the client-side application rather than hidden behind an API.

Testing the text-processing functions

The UI is only one part of the tool. The text-processing functions should be tested independently with cases such as:

Empty input
Whitespace-only input
One sentence
Multiple paragraphs
Multiple line breaks
Punctuation at the end of a sentence
Text containing numbers
Text containing Unicode characters
Text with repeated spaces

Separating the counting logic from the UI makes these cases easier to test and reduces the chance that a visual change breaks the underlying calculations.

What I learned

The main lesson was that small tools still need clear boundaries.

A sentence counter does not need an account system, a database, or a text-processing API. It does need:

A clearly defined counting method
Useful output beyond one number
Reasonable handling of empty and unusual input
Tests for the core functions
A clear explanation of what happens to user text

Local-first processing is not a complete privacy guarantee for an entire website. It is a practical architectural decision for the core task: the text entered into the tool does not need to be uploaded for the tool to work.

The finished tool is available here:

Try the TextFixHub Sentence Counter

The other TextFixHub tools are available at https://www.textfixhub.com/.