ASCII domain names ignore letter case in DNS, but URL paths can behave differently. Check the exact destination before sharing a campaign or launch link.
Domain names are not case sensitive for ASCII letters in DNS. URL paths can be. Changing Example.com to example.com does not select a different DNS name. Changing /Offer to /offer can select a different web address, depending on how the site handles requests. That distinction matters when a newly acquired domain becomes a campaign link, a printed address or the destination for an existing website.
A name that looks right on a slide is not enough. Test the exact link people will use, including everything after the domain. The domain and the path do different jobs In the illustrative address https://example.com/Offer , example.com is the host and /Offer is the path. DNS helps locate the host. The website handles the request for the path.
RFC 4343 specifies that uppercase and lowercase ASCII letters match when DNS names are compared. It does not make every part of a URL case insensitive, and it should not be read as a general rule for changing arbitrary Unicode characters. RFC 3986 separates the URL components: the scheme and host are case insensitive, while other generic components are assumed case sensitive unless their rules say otherwise.
Do not apply the domain rule to an entire pasted link. Three fictional links, two different questions These reserved example.com addresses illustrate the distinction. They are not tested live pages or instructions to change a website. https://Example.com/Offer https://example.com/Offer https://example.com/offer The first two use the same DNS name and the same path. The third changes the path.
A particular site might serve different content, redirect one form to the other, return an error for one form, or serve the same page at both addresses. Observe the actual behavior rather than assuming it from the domain. A browser may also display the host in lowercase. That is not evidence that it has tested or corrected the rest of the address.
What Google says about capitalized paths Google's URL structure guidance says it treats paths such as /APPLE and /apple as distinct URLs. If your server treats upper and lowercase versions as the same page, Google recommends consistent case so it can more easily identify that relationship. This is not a promise of higher rankings and not a reason to rename every existing URL.
First determine whether the variants represent the same content. A preferred canonical URL, a working visitor redirect and consistent internal links are separate things to review. A canonical tag does not itself redirect a visitor who follows the wrong link. A small acceptance check before you share the link Keep the approved destination literal. Copy the complete intended public URL into the launch brief.
Preserve the path, query string and capitalization supplied by the responsible website owner. Compare the actual campaign output. Check the clickable destination in the final draft, not just its visible label. For a QR code, inspect the encoded destination before distribution. This is a review step, not a reason to send a campaign. Test the approved page.