Make sure that email validators don't match unintentional non-ASCII local parts

[tats-u]

Follow-up of #1068

EMAIL_REGEX has the same problem as RFC_EMAIL_REGEX.

Also added a test case to email and rfcEmail. The latter has already been assured to be passed thanks to #1068.

Summary by CodeRabbit

• Bug Fixes
  • Improved email validation to more consistently reject malformed addresses that include non-ASCII characters.
  • Updated the underlying email-matching rules for Unicode-related edge cases to ensure consistent rejection.
• Tests
  • Expanded invalid-email test coverage for non-ASCII input by adding additional malformed examples.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
valibot	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 26, 2025 10:11pm

[tats-u]

\w matches the following characters with iu flags:

017F; C; 0073; # LATIN SMALL LETTER LONG S
212A; C; 006B; # KELVIN SIGN

I doubt you know this fact. Internationalized emails are not considered by the current regex even now. This is an unintended behavior and should be fixed.

This is also a discussion in the WHATWG HTML tracker (which directly concerns the rfcEmail rule since it's using the HTML spec as its source): whatwg/html#4562

Discuss it only in WHATWG, then Valibot will change only RFC_EMAIL_REGEX. EMAIL_REGEX isn't concerned with the WHATWG spec.

I'll also note that the current regex used by the email validator does not account for valid characters such as '

EMAIL_REGEX has lower quality and is less practical than RFC_EMAIL_REGEX. EMAIL_REGEX is discouraged in my opinion. It exists only for backward compatibility. It should be changed in v2. Where did it taken from?

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/valibot@1075

commit: eb61a6d

[tats-u]

In the first place what "internationalized email addresses" match that regex?
I doubt there are ones using non-ASCII characters other than K and ſ.

SMTPUTF8 is not supported by all MTAs. Who uses non-ASCII characters as a local part?

[tats-u]

Have you seen https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Character_class_escape#w? What "accented letters" match \w?

[cyyynthia]

Oh damn it, I mixed up regex flavors again... 😖 You're right here, JS' unicode flag doesn't do anything useful here; for some reason I was thinking with PCRE regex behavior in mind... 🙃

I marked my original comment as resolved, sorry for the confusion! ❤️

I'll open a separate issue for internationalized email support, as I still think it's an important thing to address nonetheless

[tats-u]

You should confirm detailed definitions of character classes in each language unless you are used to them.

e.g. C#: https://learn.microsoft.com/en-us/dotnet/standard/base-types/character-classes-in-regular-expressions#word-character-w

[fabian-hiller]

Just as a quick clarification... there is still interest in merging this PR? If so, I will review in soon.

[fabian-hiller]

I took a quick look and am not sure if I want to merge it. email is intentional "stricter" and disallows many uncommon things. Maybe it it better to leave this as is and recommend rfcEmail instead.

[tats-u]

there is still interest in merging this PR?

Sure

disallows many uncommon things

This PR also disallows uncommon cases. I don't think you assume or know \w with iu matches the Kelvin symbol and the small long S.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 2a22903e-94f6-492a-81e4-bf734c8d8c0a

📥 Commits

Reviewing files that changed from the base of the PR and between 62fd4e4 and 4929806.

📒 Files selected for processing (1)

• library/src/regex.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• library/src/regex.ts

---

Walkthrough

The email regex now uses only the case-insensitive i flag, with targeted eslint rule disables. The email and RFC email test suites add Kſ@example.com to their invalid non-ASCII email cases.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly matches the main change: tightening email validators to avoid unintended non-ASCII local-part matches.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Pull request overview

This PR updates Valibot’s email validation regex to prevent unintended matches of non-ASCII characters in the local part (a follow-up to #1068), and adds regression coverage to ensure both email and rfcEmail reject such inputs.

Changes:

• Adjust EMAIL_REGEX to avoid Unicode-case-folding side effects that can admit non-ASCII characters.
• Add a regression case (Kſ@example.com) to email and rfcEmail test suites.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
library/src/regex.ts	Updates EMAIL_REGEX flags to avoid unintended Unicode/local-part matches.
library/src/actions/rfcEmail/rfcEmail.test.ts	Adds a regression test for non-ASCII local-part lookalikes.
library/src/actions/email/email.test.ts	Adds the same regression test for the email action.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[yslpn]

I think this fix is ​​good. It can be merged, no problem. On the other hand, I think this is a very rare case. I don't think any user will encounter this.