Regex tester
Matches highlight as you type, using your browser's own regex engine. That is the point: if the pattern is destined for JavaScript, this is the exact engine it will run against rather than a reimplementation that differs in the corners.
Capture groups per match, flags as toggles, and a replacement preview. Nothing is sent anywhere.
2 matches
| # | Match | At | Capture groups |
|---|---|---|---|
| 1 | hello@briskfile.com | 9 | 1: hello 2: briskfile |
| 2 | sam@example.com | 32 | 1: sam 2: example |
Nothing is uploaded. Matched in this tab. No request carries it.
The flags, and what each is really for
| Flag | Does | Reach for it when |
|---|---|---|
g | Finds every match, not just the first | Almost always. Its absence is the commonest surprise in regex |
i | Ignores case | Matching words people typed themselves |
m | Makes ^ and $ match at each line | Working line by line through a block of text |
s | Lets . match a newline | Matching across lines, which . otherwise refuses to do |
u | Full unicode handling | Anything with emoji or non-Latin scripts in it |
Greedy against lazy, which explains most bad matches
By default a quantifier is greedy: .* takes as much of the string as it possibly can and then
hands back only as much as it must for the rest of the pattern to fit. Add a question mark and it becomes lazy,
taking as little as possible and expanding only when forced.
The classic demonstration is matching a tag. Against <a>text</a>, the pattern
<.*> matches the entire string — it grabbed everything, then backed up to the last
>. The pattern <.*?> matches <a>, which is nearly always
what was wanted. If a pattern is matching far more than it should, this is the first thing to check.
Why patterns are usually written against real data
Nobody tests a regex against invented text. They paste in the actual log lines, the actual email addresses, the actual customer export — because a pattern that works on a tidy example and fails on the real thing is the entire problem being solved.
Which is exactly why this runs locally. The data you need to test against is usually the data you should be most careful with, and the two facts are in direct conflict on every other regex site.
The HTML question
Regular expressions cannot reliably parse HTML, and the reason is precise rather than snobbery: HTML nests to arbitrary depth, and a regular expression has no way to count how deep it currently is. Any pattern you write will be correct on the documents you tried and wrong on some other perfectly valid one.
Use a parser for anything structural. For pulling a single attribute out of markup whose exact shape you control, a regex is a perfectly reasonable tool and the purists can look away.
Questions
How do I test a regular expression?
Type the pattern, paste some text to match against, and the matches are highlighted as you type. Capture groups are listed per match, and you can try a replacement to see what the result would be.
Which regex flavour is this?
JavaScript’s, because it is your browser’s own engine doing the matching rather than a copy of one. That is deliberate: if you are writing a pattern for JavaScript, testing it against a reimplementation would be testing something subtly different from what will run.
Why does my pattern only find the first match?
Because the g flag is off. Without it a regular expression stops at the first match by design. It is the single most common surprise in regex, and toggling g here fixes it immediately.
What is the difference between greedy and lazy?
.* is greedy: it takes as much as it can and then gives back only what it must. .*? is lazy and takes as little as possible. Matching <a>x</a> with <.*> swallows the whole string; <.*?> matches just <a>. Most "my pattern matches too much" problems are this.
Is my text sent anywhere?
No. Patterns are usually written against real data — log lines, email addresses, customer records pasted in to check a rule works — and none of it leaves this tab. The page runs with the Network tab open.
Can a regular expression parse HTML?
Not reliably, and it is worth knowing why rather than just being told no. HTML nests arbitrarily deep and regular expressions cannot count nesting, so any pattern you write will be wrong on some valid document. Use a parser. For pulling one simple attribute out of markup you control, a regex is fine.
What BriskFile will not do to you
-
Your files never leave your device
Every conversion runs in your browser. Open DevTools, watch the Network tab, and you will see no upload — because there is not one.
-
No account, no email, no watermark
Nothing to sign up for and nothing stamped on your images. There is no step between choosing a file and getting it back.
-
No limits at the download button
No daily cap, no file counter, no "upgrade to download". If the tool starts a job, it finishes it.
-
Checkable, not just claimed
Open the Network tab and convert something — nothing goes out. Or load the page, disconnect, and watch it keep working: the tool is already on your machine, and your file never leaves it.