Unfortunately, RegExr does not color-code the different capturing groups.
For example, replace the RegExr sample regex with "([A-Z])\w+\s\w(\d.\d)" and compare[1][2] its color coding capability to the other regex helpers.
The other sites such as regex101.com & debuggex.com will delineate the capture groups within the matched text using different colors. This is very helpful for complex captures because making the boundaries visible can reveal bugs in your thinking of what substrings the regex is actually capturing.
(I don't intend to be negative. If capture group color-coding is an easy coding enhancement for RegExr, consider my comments as mentioning a minor nit.)
Just wanted to chime in and give my recommendation for regex101.com that parent links to. This is by far the best regex "composer" I have ever used, on or offline.
It is actually true for PCRE (PHP), Python, and and a bit for non-global Javascript regex. For global matches in JS it is, I dare to say, incredibly difficult, if not impossible. I haven't seen visualised submatches in JS anywhere. I'd be happy to be mistaken and corrected.
So go on, try it right away :] I think it might be possible to get it done with breaking original regexp into group tree and look what each part did on concrete match from global search using non-global match on local instances. You'd need own regex parser and watch out for deep nesting.
Then I think I misunderstood what jasode was asking. Specifically, the example (our link) already names groups if you hover over matching text (group #1, etc) - I thought they were just asking for the highlight color to correspond to the group # listed.
Thanks for mentioning the tooltip popups. I didn't realize RegExr used mouseover/hover events on the matching text since the other regex sites don't do that. (It seems like non-obvious UX/UI but I now notice that the bottom left corner does say "Roll over a match or expression for details" -- but who reads the instructions?!?! Nobody's got time fo 'dat.)
Nevertheless, I prefer explicit color-coding highlighting the boundaries instead tooltips displaying the offset numbers.
Interesting, somehow I just instinctively moused over the text when I first visited the page. Another example of the subjectivity of UX and need for UI to be explicit and versatile I guess.
yes, I only knew about the hovering because of the instructions, which I did read. FWIW, my reaction was it would probably be better if they were all visible at once, who has time to hover over stuff.
anyway since they have the logic to already know what to put in the tooltip, making that number determine a color seems like it would be simple, almost as simple as appending it to the tooltip. (if indeed that's all that's missing.)
Debuggex actually has the /g flag always enabled (the example above happened to have just one match), and it works for JS [1]. Groups for JS are indeed quite tricky. However, they come for free if you implement state visualization, since you need your own regex engine to do that (and can use said engine for the position of groups).
In my examples, it looks like debuggex didn't match "\s" to newline in "...Z\n0..." but regex101.com does.
I don't know if that behavior for not matching newline matching is desirable since "\s" is supposed to include [ \t\r\n\f]. (See [1]) In any case, there doesn't seem to be an option in debuggex to make it behave like regex101 for my specific example.
Interesting. That's very subtle behavior. (Especially since it sometimes fools one into thinking /g option is not enabled when in reality, it's a CR+LF issue.)
I'm not saying your site's interpretation of Windows CR+LF is "wrong" but the other 5 online[1] regex testers don't behave that way on Windows Chrome browser. I also tested the regex and target text on desktop JGSoft RegexBuddy[2]. None of those required "\s\s" instead of "\s".
Debuggex at the least, is very idiosyncratic since the majority of the other testers don't treat CR+LF that way.
[1]regex testers tried with "([A-Z])\w+\s\w(\d.\d)" on Windows:
Neither choice is great (the other ones that I've tried auto-convert \r\n to \n so it's impossible to test a \r\n string). I don't think there's anyone in particular that's at fault, \r\n causes a messy set of problems.
I'd add http://regexpal.com/ for historical completeness. It's the first such tool I used and prefer it even today. Very sad that from what it seems Steven Levithan sold entire domain recently and is not updated anymore. Even permalinks broke last year. (I'm a bit worried, what's up with Steven.)
That doesn't make it "better", but it does mean they have slightly different purposes. You can use Ruby specific regex features with Rubular, so it is "better" for Ruby regex development.
As a general principle, I like to test against the same regex engine that I'll use in production. If I'm writing Ruby, I'll use pry/irb or a tool like Rubular. If I'm writing Javascript, you'll find me in the closet with the barrel of a gun in my mouth... I mean, I'll test against my target browsers using their respective web inspector, or use a tool like RegExr.
An example of the differences in the engines, the Onigmo engine supports conditional sub-patterns:
As far as browsers go, they're actually pretty close most of the time. ECMA specifies regex (I think), so if you stick to the ECMA standard, you should be fairly safe. As with anything in browser-land, you'll encounter edge-case inconsistencies that will bite you in the ass.
Rubular is my go to as well, even though I primarily write JS expressions and there are some gotcha.
Having the numbered capture groups and clean simple interface is amazing. I also test and create tiny urls embedded in my code to show how the expression work. Handy for coming back later and making changes.
I don't doubt there is something better, but it is still hard to change.
For me, it's lightning fast with no clutter. I just want quick verification that the regex I'm writing matches a few samples. Explaining to me that `+` matches "one or more of the preceding group" adds no value.
I've been programming for about two decades. I had composed three regexes before my first coffee and before seeing this article this morning. My problem: I still don't have a good mnemonic to remember how magic differs grep, egrep, vim, awk, Perl, Python, etc. If that this site had modes and flavoured cheat-sheets I would live there!
I love and miss RegexBuddy! If only they had a Mac/Linux version :( I've had thoughts about switching back to Windows while developing complex regular expressions.
What I am missing is some kind of service to convert between different types of regexes. Like Java, Intellij Idea Search&Replace, vim, less, grep, egrep, sed. There are subtle (and sometimes not so subtle) differences between them which I always forgetting and have to trial&error a bit.
I wish there would be one single standard to regexes. Great tool but difficult to use because of many incompatible implementations.
Sites like this is great and all, but I wish they included some commonly used regexes. Like a list of 'good' regexs to validate phone numbers, emails and other common stuff.
It would actually be pretty cool to have a site like this except you could add the regex to a list, and then people could upvote the regexe depending on the quality of it.
You can only validate a zip code, a phone number, an address, or an email address using a regex up to a point.
There are too many dispartities from a country to the next for the first three to hope validating anything withhout a bunch of false negatives. Some countries don't have zip codes.
For emails, blindly following the RFCs yields a monster (see [1]), and it won't help you if you run into oddball email addresses that are not RFC-compliant but work regardless due to technical implementations (or vice versa).
I've been looking for something like this on mac since I moved away from windows long time ago, no RegEx Buddy, such a great tool too. I think that I discovered regexr a year ago. This is such a great tool. Much appreciated work from @gskinner and community.
I really like the regexp syntax coloring. What makes me still reach out for rubular.com, is actually the regexp cheat sheet on the bottom of the page. After 25 years, I still like to have a cheat sheet for regexp to remember all the swithces etc.
Probably my favorite tool on the internet. One thing I wish it had was an implicit select option like grep -o since I frequently find myself using it to do interactive text manipulations for one offs.
For example, replace the RegExr sample regex with "([A-Z])\w+\s\w(\d.\d)" and compare[1][2] its color coding capability to the other regex helpers.
The other sites such as regex101.com & debuggex.com will delineate the capture groups within the matched text using different colors. This is very helpful for complex captures because making the boundaries visible can reveal bugs in your thinking of what substrings the regex is actually capturing.
(I don't intend to be negative. If capture group color-coding is an easy coding enhancement for RegExr, consider my comments as mentioning a minor nit.)
[1]https://regex101.com/r/eB5jY1/1
[2]https://www.debuggex.com/r/mci3WLNmHGTEatf6
(couldn't find a way to enable /g global on debuggex.com (even tried PCRE option) but color boundaries still show up on the 1st capture group)