All Tools
T

Line Sort / Unique / Deduplicate

Sort lines, remove duplicates, or do both locally in your browser without losing meaningful blank lines by default.

Read the full guide for this tool

0 chars | 0 words | 0 lines

Ctrl/Cmd+Enter transforms | Ctrl/Cmd+K clears

Unique mode compares whole lines only. Leading and trailing whitespace stays meaningful, so banana and   banana are different lines.

Sorting uses the browser's localeCompare()behavior. Case-insensitive mode folds case for compare and dedupe, but exact collation details can vary slightly by browser locale.


Line Sort / Unique / Deduplicate: Clean Up Text Lists Fast

You have a messy block of text: repeated emails, duplicated IDs, copied log lines, or a newline-separated list that needs to be ordered before you diff it. A line sort / unique / deduplicate tool is the quickest way to sort lines, remove duplicate lines, and get a stable list you can actually work with.

This tool lets you sort text lines online without sending data to a server. Processing runs in the browser, so pasted lists stay local to your machine. That matters when the input contains internal URLs, customer IDs, stack traces, or anything else you would rather not upload.

What it does

The core operations are simple:

If your input is:

banana apple banana Cherry

you might want one of two outcomes:

Those are different operations, and the difference matters when you are cleaning data for code, spreadsheets, config files, or search indexes.

Using it

Paste your newline-separated text into the input. Choose whether to sort, deduplicate lines, or do both. If the tool exposes options for case sensitivity, blank lines, or sort direction, set those before running it. Then copy the cleaned output back into your editor, terminal, or spreadsheet.

Typical workflow:

  1. Paste raw input
  2. Enable Unique if you want to remove duplicate lines
  3. Choose ascending or descending sort if order matters
  4. Decide whether matching should be exact or case-insensitive
  5. Copy the result

Common developer use cases

Exact duplicates vs case-insensitive duplicates

This is the first thing to get right.

With exact matching, Foo, foo, and FOO are three different lines. With case-insensitive matching, they collapse into one logical value. Neither behavior is universally correct.

Use exact matching when case is meaningful, like passwords, case-sensitive tokens, Linux paths, or identifiers that should not be normalized. Use case-insensitive matching when you are cleaning emails, tags, hostnames, or user-entered lists where Admin and admin should count as the same item.

If you deduplicate case-insensitively, the output still has to keep some original spelling. Most tools keep the first encountered variant, which means Foo may survive while later foo lines are removed.

Sorting is not always as deterministic as it looks

When you sort lines in a browser, ordering is usually based on JavaScript string comparison and locale-aware collation rules. That means uppercase, lowercase, accents, punctuation, and numbers may not always sort the way sort does in your shell.

For example, item2 and item10 may sort differently depending on whether the comparison is plain lexical or locale-aware with numeric handling. Z may come before a, or case may be treated as equivalent depending on the implementation. For everyday text cleanup this is fine. For strict build pipelines, use the browser tool to inspect and clean the list, then verify with your production script if byte-for-byte ordering matters.

Blank lines and whitespace

Blank lines are easy to overlook. Sometimes they are noise from copy-paste. Sometimes they are intentional separators.

If blank lines should be ignored, remove them before or during deduplication. Otherwise a blank line is just another line value and may remain as one unique empty entry. The same goes for leading and trailing whitespace: apple and apple look identical in many editors but are not exact matches unless the tool trims them.

A single final newline is treated as the end of the last line, not as an extra blank record. That avoids turning ordinary pasted text into a leading blank line after sorting, while still preserving real empty lines that appear between or after content.

If your output looks wrong, hidden whitespace is usually the reason.

Why this is useful before diffing

Sorting and deduplicating turns an unstable list into something reviewable. If two files contain the same values in different orders, a raw diff looks noisy. Sort both and the real changes become obvious.

This is especially useful for:

The browser-based tool is faster than writing a one-off command every time, but it maps cleanly to CLI habits like sort, uniq, and sort -u.

Troubleshooting

Why are some duplicates still there? — The lines may differ by case, leading or trailing spaces, tabs, or other invisible characters. foo, Foo, and foo are not exact duplicates.

Why did the sort order look different from my terminal? — Browser sorting can use different collation behavior than shell tools. Locale, case handling, and numeric comparison all affect the final order.

Why is there still one blank line in the result? — If blank lines are allowed, deduplication usually keeps one unique empty line rather than removing all of them.

Why did item10 sort before item2? — Plain lexical sorting compares character by character, so 1 comes before 2. Natural or numeric-aware ordering is a separate behavior.

Is this safe for sensitive data? — The tool runs locally in the browser, so line sorting and deduplication happen on your device rather than being uploaded for server-side processing.