Regular expressions are quicker to test than to reason about, and testing them somewhere that runs the same engine as the code matters — this page uses your browser's own JavaScript regex engine, so what matches here matches in your script. Every match is highlighted in the text, listed with its position and its captured groups, and you can preview a replacement with $1-style references before committing to it. Test text tends to be real data, so it is worth saying: nothing you paste leaves the page.
JavaScript's, because it is your browser's own engine running the pattern. It is close to PCRE for everyday work, but lookbehind, named groups and Unicode property escapes have their own support history, and some things PCRE allows — recursion, possessive quantifiers — do not exist here at all.
No. The pattern runs in the page against text that never leaves it. That is worth knowing when you are testing against a log excerpt or a customer record.
Because a pattern can be made to backtrack catastrophically — nested quantifiers over the wrong input take exponential time — and a browser cannot interrupt a regex once it starts. Capping the input keeps a bad pattern from freezing the tab instead of showing you the problem.
Rendering tens of thousands of highlighted matches would make the page unusable without telling you anything more. When the cap is reached it is stated above the results, so you know the list is partial.
They appear as an object in the groups column, and you can reference them in a replacement with
lt;name>. A pattern like (?<year>\d{4}) makes the year available under that name instead of a number.