Will a canonical tag force Google to use my URL?

No. It is a strong signal, not a guarantee; search systems combine it with redirects, sitemaps, internal links, and content evidence when deciding which URL to index.

Why was the #fragment removed from my URL?

Google generally does not support fragment URLs as canonical targets, and a fragment identifies a location within a representation rather than a separate network resource, so the tool targets the underlying resource URL.

Should query parameters always be removed from a canonical?

No. The correct target depends on your content and routing. The tool preserves intentional query strings instead of guessing which ones are tracking noise.

Can I use a relative URL inside the href attribute?

No. The generator requires an absolute URL with scheme and host because relative paths change meaning with document location and deployment environment.

What a Canonical Tag Is Used For and How to Build One

A canonical tag is used to declare a single preferred URL when the same or substantially similar content is reachable at more than one web address, telling search engines which version to treat as the master copy. The tag itself is a single HTML link element placed inside the page head: <link rel="canonical" href="https://example.com/preferred-page/" />. When multiple URLs show duplicate or near-duplicate content, whether through tracking parameters, www and non-www host variants, protocol differences, or syndicated reposts, the canonical tag consolidates crawl, indexation, and link-equity signals onto one address. Search engines combine that signal with redirects, sitemap entries, internal links, and the content itself when deciding which URL to index, so the canonical works as a strong hint rather than a binding instruction. Used correctly, it prevents duplicate-content dilution, keeps analytics clean, and protects rankings when pages have to exist at several URLs by design. The Canonical Tag Generator takes the absolute HTTP or HTTPS URL you want to prefer and turns it into that exact link element, normalized through the browser URL parser and HTML-escaped for safe pasting.

canonical tag used for — What a Canonical Tag Is Used For and How to Build One

When a Canonical Tag Is the Right Fix

Several scenarios make a canonical tag the appropriate response rather than a redirect or a noindex. The recurring theme is the same primary content being reachable through more than one URL while every duplicate must remain publicly accessible.

Parameterized tracking or sort URLs that change nothing important about the page, such as ?utm_source=, ?sort=price, or ?ref=newsletter, can list the clean URL as canonical so the parameters do not fragment indexing.
Syndication, republishing, or partner rehosts of your article should declare your original URL as canonical on each copy.
Paginated or filtered views of the same product, category, or article that cannot collapse with redirects still need one canonical target.
www versus non-www host variants and http versus https protocol variants can each carry a canonical pointing to the chosen form, although a redirect is the cleaner long-term answer.
AMP or alternate presentation layers that share primary content with the canonical desktop page declare the desktop URL as canonical.
Self-referential canonicals on the preferred page itself are widely recommended because they reinforce the signal even when no duplicate exists.

If the duplicate page should no longer be served at all, use a 301 redirect instead. A canonical does not remove a URL from search immediately and does not redirect users, so it is the wrong tool for retired pages.

Anatomy of a rel="canonical" Link Element

The element has a fixed structure. The required pieces are rel="canonical" and an href attribute containing the absolute preferred URL:

Three rules matter most when you write or paste this element by hand. The element lives inside the HTML head, not in the body. The href must be absolute, including scheme and host, since relative paths such as /products/widget change meaning with document context and are not accepted by the generator. The href must point to a page that returns a 200 status with equivalent primary content; pointing it at a 404, a soft-404, or an unrelated page confuses the signal and weakens every other canonical on the site.

Ampersands inside the href get written as & so the attribute stays valid HTML. The displayed URL keeps the ordinary & character; this difference is expected and the requested resource is unchanged.

Build the Tag Step by Step

Use this sequence when generating and deploying a canonical tag with the browser-side tool.

Enter the complete preferred URL in the input field, including the scheme (http or https), host, path, and any query string that is part of the deliberately chosen canonical address. Leave out fragments, since they will be removed during parsing.
Generate the tag and review the normalized URL the tool returns. Compare it character by character against the real 200 page you want search engines to prefer, paying attention to host case, default ports, and any Unicode-to-ASCII domain transformation.
Copy the produced <link rel="canonical" href="..."> element from the output area.
Paste it inside the <head> of the page whose primary content matches the canonical target. For duplicate pages, the element names the preferred URL; for the preferred page itself, the element is self-referential and points back at its own address.
View the delivered HTML in a browser or inspect the document head on the live URL. Confirm there is exactly one canonical element, that its href resolves to a 200 page with equivalent primary content, and that page templates across representative routes behave the same way.

If your CMS auto-injects a canonical tag, disable that feature or align its output before pasting your own element, or the two will compete and weaken the signal.

Normalization Rules the Generator Applies

The generator parses the input through the browser URL implementation, the same WHATWG URL Standard that powers address bars and fetch clients. The transformations are deliberate rather than guessed. The table below summarizes what changes and what stays the same.

Input form	What the generator produces	Reason
https://Example.com/Page	https://example.com/Page	Hosts are lowercased per the URL standard; path case is preserved.
https://example.com:443/page	https://example.com/page	Default port 443 is stripped from HTTPS.
https://example.com:80/page	https://example.com/page	Default port 80 is stripped from HTTP.
https://example.com/page#details	https://example.com/page	Fragments identify a location within a resource, not a separate network object.
https://xn--fsqu00a.xn--0zwm56d/page	https://xn--fsqu00a.xn--0zwm56d/page	Internationalized domains and non-ASCII paths are punycoded to their ASCII-compatible form.
https://example.com/page?utm=mail&ref=blog	Same URL in the output, with & between params in the HTML attribute	Query strings are preserved because they may be part of a chosen canonical; ampersands are escaped for valid markup.
/products/widget	Rejected	Relative paths are rejected because their meaning depends on document location.
ftp://example.com/page	Rejected	Only HTTP and HTTPS are accepted; ftp, javascript, data and other schemes are not valid targets.
https://user:[email protected]/page	Rejected	Credentials embedded in URLs are rejected to keep the canonical public.

For the full reference on each rule, the Canonical Tag Generator Cheat Sheet walks through the eight standards-aligned fixtures the tool is tested against.

What the Generator Deliberately Does Not Decide

A canonical tag generator cannot read your CMS, your routing table, or your content. Several decisions must stay in your hands, because guessing would risk pointing the canonical at the wrong page and silently hurting indexation.

The tool does not force HTTPS or strip HTTPS; if your site serves both schemes, the redirect layer decides which form is canonical.
The tool does not add or remove www; host canonicalization is a site-wide decision handled at the edge or in the application config.
The tool does not enforce a trailing-slash policy; the path you enter is the path that ships.
The tool does not remove tracking parameters; query strings stay exactly as you wrote them so that an intentional canonical like ?product=red survives untouched.
The tool does not resolve redirects; if your input URL 301s somewhere else, the canonical points at the input, not the destination.
The tool does not compare page similarity; it cannot tell whether two pages really are duplicates, only normalize the URL you provide.

Keep these decisions in your redirect map, sitemap, and content audit so the canonical stays consistent with everything else.

Validate the Delivered Page After Pasting

Generating the tag is half the work. The other half is confirming the live page carries the intended signal, because a canonical that conflicts with another canonical, with an HTTP header canonical, or with sitemap entries weakens all three signals at once.

View source on the live URL and confirm a single <link rel="canonical" ...> element appears in the head.
Inspect the HTTP response and confirm there is no competing Link: <...>; rel="canonical" header with a different href.
Cross-reference the canonical href against your sitemap and your main internal links; all three should agree on the preferred address.
Spot-check a handful of representative templates, such as product, category, article, and paginated archive, because one successful page does not prove every generated page is correct.
Re-run the check after any CMS, theme, or framework upgrade that touches the head template.

According to Google's canonicalization documentation, a canonical is a strong signal rather than a directive, so the more consistently every signal points to the same URL, the more reliably that URL is selected.

For a deeper look, see Meta Tag Generator for Beginners: A Plain-English Guide.