Online Tool Store
Column Splitter
Splits a column by delimiter, regex, fixed widths or character positions. A limit caps the number of cuts and keeps everything after the last one, unlike a plain split which discards it. Reports how many parts each row produced so inconsistent data is obvious.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
Split in this page; nothing is uploaded. This splits text mechanically — it does not understand what your data means, which matters most for names. See the notes below before splitting a name column.
How to use it
- Paste a CSV, or tick the plain-lines option to treat each line as one value.
- Choose the column and how to split it.
- Read the part-count report — that is how you tell whether the split worked.
- Copy or download the result.
A limit should not discard your data
This is a genuine bug in the obvious approach, and worth knowing even if you never use this tool. JavaScript's
split takes a limit, but that limit caps the length of the returned
array rather than the number of cuts — so the remainder is thrown away:
value DATABASE_URL=postgres://user:pass@host:5432/db?x=1
native split('=', 2)
→ ["DATABASE_URL", "postgres://user:pass@host:5432/db?x"]
the trailing =1 is gone
here limit 1
→ ["DATABASE_URL", "postgres://user:pass@host:5432/db?x=1"]
So a limit here means "make at most this many cuts, and keep everything after the last one". That is what you want for splitting a key from a value, a path from a filename, or a prefix from a code. The direction is a choice too — counting from the end is how you separate a file extension or a last name without knowing how many parts precede it.
Names are the trap
Splitting a full name into first and last is the single most common reason people reach for a tool like this, and it is the case where mechanical splitting does the most damage. Taking the first token as the first name and the rest as the surname:
Ada Lovelace → Ada | Lovelace fine
Jan van der Berg → Jan | van der Berg fine
Smith, John → Smith, | John inverted, comma kept
Prince → Prince | empty surname
Dr. Grace Hopper → Dr. | Grace Hopper title as first name
Two of those five are fine and three are wrong in ways that will not be obvious once the data is in a database. The inverted case is the worst, because "Smith, John" is a completely normal way for an export to be formatted and the result looks plausible.
There is no setting that fixes this, because the problem is that a name is not a delimited record. What helps is the part-count report: if your name column produces two parts for most rows and one or four for the rest, those are precisely the rows to look at. Split, then check, then correct — and if the source system can give you separate fields, ask it for those instead.
Widths, positions and what happens to the remainder
Fixed-width splitting is for data with no delimiter at all — timestamps run together, product codes, fixed-format exports from older systems. Widths are lengths; positions are offsets. Both keep anything left over:
"20260817ABC1234" widths 4,2,2 → 2026 | 08 | 17 | ABC1234
"short" widths 3,5,5 → sho | rt | |
"2026-08-17T14:30" positions 10 → 2026-08-17 | T14:30
That trailing ABC1234 matters. A tool that only emits the columns you
declared would drop it, and you would not notice until something downstream was missing an identifier. A value shorter than the
declared widths produces empty columns rather than an error, which keeps the output rectangular.
Regex, and the honest gap
Regular expression splitting handles the cases a fixed delimiter cannot — runs of dashes of varying length, splitting on any of
several characters, or a lookahead like (?=[A-Z]) that splits
CamelCase without consuming anything.
The limit control is disabled in that mode, and that is deliberate rather than an oversight. Capping a regex split correctly means rejoining the tail with the exact separators that were consumed, and a split does not tell you what it matched — so a limit could only be approximated. Offering a control that quietly did nothing would be worse than not offering it, so it greys out and the reason is stated here.
FAQ
Why does "split at most once" keep the rest of the value?
Because the alternative loses data. JavaScript's own split with a limit caps the length of the array rather than the number of splits, so splitting DATABASE_URL=postgres://user:pass@host:5432/db?x=1 on the equals sign with a limit of 2 returns the key and postgres://user:pass@host:5432/db?x — the trailing =1 is silently gone. Here the limit caps the number of cuts and everything after the last one becomes the final part, which is what splitting a key from a value actually needs.
Should I use this to split names into first and last?
Only with your eyes open. Splitting on the first space gets Ada Lovelace right and then quietly mangles a lot of real data: "Smith, John" yields a first name of "Smith," with the comma attached and the names inverted, "Prince" leaves the surname empty, and "Dr. Grace Hopper" makes the title the first name. This tool splits text mechanically and does not pretend to understand names — check the part-count report and expect to fix rows by hand.
What does the part-count report tell me?
Whether your column is actually consistent. If every row splits into the same number of parts you can trust the result. If some give two and others four, either the data is irregular or you are splitting on the wrong thing — and that is far easier to see in a count than by scrolling through output. Rows that produce fewer parts are padded with empty values so the result stays rectangular.
How is fixed-width splitting different from positions?
Widths are lengths and positions are offsets. Widths of 4,2,2 on 20260817 give 2026, 08 and 17 — each number says how many characters to take. Positions of 4,6 on the same value cut at those offsets, giving 2026, 08 and 17 as well, but the numbers mean something different as soon as the fields are not adjacent. Both keep any remainder as a final column rather than discarding it.
Why can I not set a limit when splitting by regex?
Because capping a regex split correctly would require rejoining the tail using the exact separators that were consumed, and a split does not report what it matched. Rather than offer a limit that quietly does nothing, the control is disabled for that mode. If you need a limited regex split, use a lookahead so nothing is consumed, or split by delimiter instead.
Is my data uploaded?
No. Everything is parsed and split in the page, which matters because the columns people split are usually names, addresses and account identifiers.
How we compare
| Feature | Online Tool Store | Text to Columns in a spreadsheet | A formula or script |
|---|---|---|---|
| Data never leaves your device | ✓ | Depends | ✓ |
| A limit that keeps the remainder | ✓ | ✗ | If you write it |
| Reports how many parts each row produced | ✓ | ✗ | ✗ |
| Splitting from the end | ✓ | ✗ | If you write it |
| Never reformats your values on the way in | ✓ | ✗ | ✓ |
| Understands names, addresses or dates | ✗ | ✗ | With a library |
| Files too large for a browser tab | ✗ | Row limits | ✓ |
The advantages over a spreadsheet's Text to Columns are the limit that keeps the remainder, splitting from the end, and not having your identifiers reformatted into scientific notation on import. It has no understanding of what your data means — for names in particular, treat the output as a draft and use the part-count report to find the rows that need a human.