Text Extractor

Features

• Eleven kinds: links, emails, phones, IPs, MACs, Chinese IDs, card numbers, dates, hashtags, @mentions and numbers
• Six presets to switch between: common, everything, network, contact, sensitive and numbers only
• ⚠️ Only certain matches — phone numbers limited to known ranges, IPs validated octet by octet, card numbers required to pass Luhn, IDs required to have a correct check digit
• Grouped by kind, each hit with its positions in the text (1-based, counted in code points so emoji do not shift them) plus a summary count
• ⚠️ Optional “comma as decimal point” (`3,14` → `3.14`), off by default because `1,234` means twelve hundred and thirty-four in English usage
• ⚠️ Overlapping links and emails are counted once (links win), so nothing is tallied twice
• Deduplication is by value: emails ignore case (the same address), links respect it (path case is often two different pages)
• ⚠️ When card numbers are found, a note says that passing Luhn does not make it a card, pointing at the checksum validator
• Paste as many lines as you like; results are ordered by position

How to use

1. Paste the text
2. Pick a preset under “What to extract” (the default is the four common kinds)
3. Results are grouped by kind, with a summary count at the top

FAQ

Why was an obvious phone number skipped?

Because a number without a country or area code cannot be confirmed. A ten-digit run could be a phone number, an order number, part of an ID or a timestamp — and a result of “37 phone numbers” with 20 order numbers mixed in makes the user check every one, which is worse than nothing. So only Chinese 11-digit mobiles starting `1[3-9]` and international numbers written with an explicit `+` are taken. For other shapes a regex is the right tool (the regex tester on this site shows matches as you type).

Why must a card number pass Luhn?

Because matching by length alone drags in everything: runs of 13 to 19 digits are all over a log — order numbers, timestamps, long IDs. Luhn filters out about nine in ten of those, but not all: a long number that happens to satisfy Luhn still gets through. So check the individual values with the checksum validator, which explains that a passing checksum does not mean the card exists.

Are overlapping links and emails counted twice?

No. `https://example.com/?to=a@b.com` contains both a link and something shaped like an email, and the link match is wider — without handling that, the same span would be counted once by each category and the summary would be inflated. This is handled with occupied ranges: categories are scanned most specific first, and spans already claimed are skipped by later ones.

Why does deduplication respect case for links but not for emails?

Because case means different things in each. `a@b.com` and `A@B.COM` are the same mailbox (domains are case-insensitive, and the local part is in practice), so they should count once. But `https://x.com/A` and `https://x.com/a` are two different pages on many servers — merging them would make the user think there is only one link.

Why is “comma as decimal point” off by default?

Because a comma inside a number is ambiguous. In much of Europe and South America `3,14` is three point one four, while in English usage `1,234` is twelve hundred and thirty-four — the same comma, a decimal point in one habit and a thousands separator in the other. Nothing in the text settles which it is, and guessing wrong changes the order of magnitude (1.234 against 1234) while the result still looks entirely normal. So it stays off until you turn it on, once you know where the data came from.

How are the positions counted?

From the first character of the text, counted in code points so an emoji counts as one character. That is why the email in `👍 a@b.com` is at position 3 rather than the 4 a string index would give. When a value appears more than once every position is listed (up to 20; beyond that only the total), and the positions are there so you can find each hit in the original.