Idna Laravel Package

Product Decisions This Supports

• IDN go/no-go: Whether to let customers register, search, share, or be addressed on non-ASCII domains (e.g., münchen.de, Arabic or CJK domains). This package provides UTS#46 to-ASCII/to-Unicode conversion, so you can store canonical punycode for DNS/HTTP and display Unicode to users.
• Display policy: Unicode vs. punycode in the UI, emails, invoices, admin tools, and logs. UTS#46 is the browser-compatible mapping, so edge cases like ß and ς behave closer to what users see in browsers.
• Build vs. buy: A pure-PHP alternative to ext-intl/ICU or symfony/polyfill-intl-idn. Relevant if you want IDNA behavior without a native extension or host-ICU dependency.
• Multi-tenant and vanity domains: Canonicalize Unicode tenant subdomains to prevent duplicate or confusable tenants; decide whether to reserve both Unicode and punycode forms.
• Security roadmap: UTS#46 mapping is a prerequisite for homograph/spoofing controls — but not sufficient on its own. Pair with confusable-detection tooling if IDN phishing is in scope.
• Compliance and SEO: ASCII canonical forms for DNS, TLS, cookies, redirects, and analytics; Unicode forms for marketing. Reduces broken redirects and certificate mismatches.

When to Consider This Package

Consider it when:

• ext-intl is not guaranteed across environments (shared hosting, minimal containers, CI) or ICU versions differ between dev and production, and you need deterministic IDNA behavior in userland.
• You specifically need UTS#46 compatibility processing — the browser-aligned mapping — rather than strict IDNA2008.
• You want to pin Unicode/IDNA tables with your application instead of inheriting whatever ICU version the host provides.
• You are building domain, URL, or email-domain validation/canonicalization and want a small MIT-licensed dependency.
• You are already in the rowbot/url ecosystem or need pure-PHP URL parsing with IDN support.

Look elsewhere when:

• ext-intl is available and acceptable — it is simpler, faster, and widely exercised. Wrap it behind your own interface and move on.
• You need strict IDNA2008 semantics rather than UTS#46 compatibility processing.
• You need full email validation, including local parts — use egulias/email-validator or equivalent.
• You need homograph/confusable detection — use ICU’s spoof checker or a dedicated library; this is not that.
• You require a large maintainer base or long-term support guarantees. Two stars and zero dependents is a real concentration risk; vendor, audit, or prefer symfony/polyfill-intl-idn unless you have a specific reason to standardize on this implementation.
• You are doing high-throughput bulk conversion — benchmark pure-PHP mapping against ICU before committing.

How to Pitch It (Stakeholders)

To executives: “This is a small MIT-licensed PHP component that lets us support international domain names without adding a native extension. It would let us serve customers on Unicode domains, canonicalize them safely for DNS and HTTP, and control whether users see Unicode or punycode. The trade-off is maintenance risk: it is a low-adoption project, so we would wrap it behind our own interface, pin the version, and keep a fallback to ext-intl or a polyfill. Recommendation: a time-boxed spike, not a platform bet.”

To engineering: “UTS#46 toASCII/toUnicode in pure PHP, no ICU dependency. Use it at boundaries: validation, storage as punycode, display as Unicode. Do not treat it as an email validator or a spoof detector. Add conformance tests from Unicode IDNA test data, pin the Composer version, and hide it behind an internal Idn service so we can swap to ext-intl or symfony/polyfill-intl-idn. Watch release cadence and be prepared to fork — MIT makes that viable.”