Email Validation
Email Validation in TypeScript
Model email validation in TypeScript with typed results, reusable helpers and safe error messages for frontend and API code. This reference is written for developers who need practical validation behavior, reviewable rules and safe examples rather than copied snippets with no explanation.
Recommended workflow
| Step | Why it matters |
|---|---|
| Return structured results | Avoid boolean-only helpers when the UI needs a reason. |
| Share fixtures | Use the same test cases in frontend packages and API tests. |
| Keep types honest | A string branded as email still needs runtime validation at boundaries. |
| Document normalization | Lowercasing domains is different from changing the local part. |
Starter snippet
type EmailCheck = { ok: true; value: string } | { ok: false; reason: string };Review checks
- Separate parsing, normalization and business rules.
- Use narrow error reasons such as empty, missing-at or invalid-domain.
- Keep regex constants named and reviewed.
- Use tests for both accepted and rejected samples.
Common mistakes
- Assuming TypeScript types validate runtime input.
- Branding an email before boundary checks finish.
- Throwing generic errors that the UI cannot translate.
Validation should help users correct input while protecting systems from bad data. Keep syntax checks, product policy, security review and deliverability checks separate.
Related Formalint references
Continue with Email Validation in JavaScript, Email Regex Test Cases, Javascript Regex Match Vs Test.