Extract emails from text, even when they are hidden

Yes, and it is a perfectly ordinary character before the @. RFC 5322 permits the punctuation set ! # $ % & ' * + - / = ? ^ _ ` { | } ~ in an unquoted mailbox name alongside letters and digits, so anna+newsletter@example.org is as valid as anna@example.org — it is simply a label the recipient added for their own filing. Some signup forms reject the plus sign anyway, which is a bug in the form rather than a fault in the address, and it is the single most common false rejection on the web.

No, and nothing running in a browser can. What is checked is shape: the length limits, where dots may and may not sit, which characters are permitted where, and whether the domain has a plausible ending. Whether anyone reads mail at that address is known only to the server that accepts it, and even that server often will not say — a domain with a catch-all rule accepts every address at SMTP time and bounces later, and probing mailboxes one by one gets you rate-limited or blocklisted for behaving like a dictionary attack. The reliable sequence is a shape check here, then a real message, then watching the bounces.

To hide them from the programs that read web pages looking for the @ sign. The habit dates from the early 2000s spam surge: a 2003 study by the Center for Democracy & Technology planted fresh addresses in public places and reported that the ones published in plain text on web pages collected nearly all the spam it recorded, while the same addresses written with the @ spelled out collected none. Modern harvesters read the common disguises perfectly well, so the practice now mostly inconveniences the humans it was never aimed at — which is the reason this page exists.

Because reading the bare words at and dot as punctuation is a guess, and a sentence like “we meet at example.com on Tuesdays” has exactly the shape of a disguised address. The guess only fires when a domain-looking tail follows, so “meet at noon” is left alone, but “meet at example.com” is not. Every row shows the words the address came from precisely so you can throw a bad guess away, and the tick box above turns the worded forms off entirely — bracketed forms like [at] and (dot) keep working when it is off, since those are never accidental.

Yes — a quoted mailbox name is part of the standard, and inside those quotes a space is legal, along with characters that would otherwise be forbidden. It is flagged here as unusual rather than wrong, because the number of web forms, CRMs and mailing platforms that will accept one is small, and a quoted address that works in one system routinely fails in the next. If you meet one in a document, the safest move is to ask its owner for a plain form rather than to argue with a signup form about the specification.

It can, but only where both mail servers agree to it. An address such as joão@correio.pt or 用户@例子.测试 needs the SMTPUTF8 extension defined in RFC 6531, and plenty of servers, especially older corporate ones, still refuse anything outside plain ASCII. Domains have a fallback the mailbox does not: a non-Latin domain can be written in its punycode form beginning xn--, which every server understands. Addresses of either kind are marked here as unusual, with the reason spelled out, rather than being called invalid.

Sixty-four characters before the @, 255 after it, and 254 for the whole thing. The last figure surprises people: it comes from the mail protocol allowing a 256-character forward path, of which two characters are the angle brackets wrapped around the address. A mailbox name of 70 characters is therefore invalid however sensible it looks, and this page reports the exact length it measured rather than a bare rejection.