A canonical URL is identified by a rel=canonical link element placed in the HTML head that names a single preferred address for a page that may be reachable through several URLs. The tag is the practical answer to the question of how to get a canonical URL signal onto a page, because the work is just a piece of HTML pasted into the head, not a server setting or a redirect. A canonical URL is generated by writing a complete absolute HTTP or HTTPS address into a tool that validates the scheme, normalizes the host and path, removes the fragment, and HTML-escapes the result into a link element. That element is then copied into every duplicate or near-duplicate page that should be treated as the same resource. The signal is a strong hint to search engines about which version to index, but it is one input among many: redirects, sitemaps, internal links, and content evidence all influence the final choice.
What a Canonical Tag Actually Does
A canonical tag is one line of HTML that looks like <link rel="canonical" href="https://example.com/page">. It sits in the <head> of a page and tells crawlers which URL you consider the preferred version. Google, Bing, and other major search engines read it as a strong canonicalization signal, which means it helps them consolidate duplicate or near-duplicate pages into a single indexed address. Without it, the same article reachable at /blog/post, /blog/post?ref=twitter, and /Blog/Post may be treated as three separate resources, splitting link equity and confusing analytics.
The tag does not redirect users and does not on its own remove a URL from the index. A page can still be crawled and served if the canonical points elsewhere, which is why production routing decisions and the tag should agree. If you actually want a URL to disappear, use a 301 redirect; use the canonical tag when several URLs must remain reachable but should be treated as one resource. The Canonical Tag Generator produces this HTML element from a single URL you type in, using the browser's own URL parser as the source of truth for what the normalized address looks like.
Accepted and Rejected URL Inputs
The generator only accepts URLs that are complete, credential-free, and use the HTTP or HTTPS scheme. Anything else is rejected before a tag is written. Relative paths are not allowed because their meaning changes with the document location and deployment environment. FTP, javascript, data, and other non-HTTP(S) schemes are not valid canonical targets in this tool. URLs with embedded usernames or passwords are rejected, because a canonical should identify a public content location, not expose credentials in markup.
Fragments are stripped from the input. Google documentation generally does not support fragment URLs as canonical targets, and a fragment identifies a location within a page rather than a separate network resource. Typing https://example.com/page#details therefore produces a tag whose href is https://example.com/page. Authentication does not change that: if content needs a login, canonicalization does not make it public or solve access control, so the right question is whether the page should be indexed at all.
| Input form | Result |
|---|---|
| https://example.com/page | Accepted; tag points to the normalized URL |
| http://example.com:443/page | Accepted; port 443 dropped from HTTPS output |
| https://Example.com/Page | Accepted; host lowercased, path case preserved |
| https://example.com/page#details | Accepted; fragment removed, href is /page |
| /products/widget | Rejected; relative path not allowed |
| ftp://example.com/file | Rejected; non-HTTP(S) scheme not supported |
| https://user:[email protected]/ | Rejected; embedded credentials not allowed |
What the Generator Normalizes (and What It Preserves)
The browser URL parser is the source of truth for what the generated href looks like. Host case is lowercased, so an uppercase host becomes lowercase. Default ports are removed, so port 80 disappears from HTTP and port 443 disappears from HTTPS. Internationalized domain names are converted to their ASCII-compatible form. A Unicode path is serialized in its browser-standard form. Path case is preserved as significant, so /Products/Widget stays exactly that way and is not folded into /products/widget, per the WHATWG URL Standard that the parser implements.
Query strings are preserved because they may be part of a deliberately chosen canonical address. The tool does not remove tracking parameters, sort query keys, force HTTPS, add or remove the www prefix, choose a trailing-slash policy, resolve redirects, or inspect page similarity. Those decisions depend on the site's routing and content; guessing them could produce a valid-looking tag that points to the wrong page. Inside the HTML attribute, ampersands are escaped as & so the markup is valid; the displayed normalized URL keeps the ordinary & character. This difference is expected and does not change the requested URL.
| Property | Behavior |
|---|---|
| Host case | Lowercased |
| Default ports (80, 443) | Removed from the href |
| Fragment (#...) | Stripped |
| Path case | Preserved exactly as typed |
| Query string | Preserved exactly as typed |
| Ampersand in href | HTML-escaped to & |
| Unicode path | Serialized in browser-standard form |
| Internationalized domain | Converted to ASCII-compatible form |
How to Get a Canonical URL Tag in Three Steps
- Enter the complete preferred HTTP or HTTPS URL, including the correct host, path, and any intentional query string. Use the absolute form with the scheme; do not paste a relative path or a URL with a fragment you want to keep.
- Generate the tag and compare the normalized URL with the real 200 page you want search engines to prefer. The browser URL parser may have changed the host case, removed a default port, or serialized an internationalized domain, so the output should be reviewed before you copy it.
- Copy the element into the HTML head, then inspect the delivered page for one consistent canonical signal. Open the live URL in a browser, view source on the head, and confirm exactly one rel=canonical element with the href you expect.
Where to Place the Tag and How to Verify
The copied element goes inside the <head>, not in the body. For client-rendered applications, make the canonical clear in the source output and avoid scripts that mutate it inconsistently after load. The generator returns markup only; it cannot edit a CMS template or verify how a framework renders the final document. If you build pages in WordPress, a practical template-level walkthrough is in How to Create a Canonical Tag in WordPress: A Practical Guide, which covers plugin settings and theme-level placement for the same tag this tool generates.
After adding the tag, view the delivered HTML or inspect the document head on the real URL. Confirm there is one intended canonical element and that its href resolves to a 200 page with equivalent primary content. Check templates across representative routes rather than assuming one successful page proves every generated page. Eight standards-aligned fixtures cover root-slash insertion, host normalization, path-case preservation, default HTTP and HTTPS ports, fragment removal, Unicode paths, internationalized domains, and query strings; separate tests assert exact HTML escaping and reject relative, unsafe-scheme, and credentialed targets.
Common Pitfalls That Weaken the Signal
A self-referential canonical on the preferred page is commonly recommended, so the page points to itself. Duplicate versions should point consistently to the same canonical target. Avoid conflicting signals such as one canonical in HTML, a different canonical in an HTTP header, and another URL in the sitemap; consistency makes the preference clearer, as described in the Google Search Central canonical documentation. Do not point a canonical at a page that returns a 404 or a soft-404, and do not point it at a page whose primary content is materially different.
Canonical tags help consolidate duplicate URL signals; they do not redirect users, remove a URL from search immediately, or replace a migration redirect. Use permanent redirects when a duplicate should no longer be served, and keep important internal links pointed at the same preferred address. If the path case, trailing slash, or www prefix varies across your site, pick one rule and apply it everywhere, because a canonical tag cannot fix a routing policy that the rest of the site ignores.
If you're weighing options, Hreflang Generator Alternative: Browser-Side Tag Builder covers this in detail.