Home / Link safety / How link scanning works
Link safety reference

How CanIShareThis Scans a Link

4 min readLink safety reference
At a glance

A useful link scan does more than ask whether a page loads. It parses the URL, follows a bounded redirect chain, inspects the final destination and response, and combines multiple warning signs into a risk assessment. A scan can reduce uncertainty, but it cannot certify that a destination is safe.

1. Parse the URL before making a network request

A scanner first separates the scheme, hostname, port, path, query and fragment. This matters because the hostname identifies the network destination while words placed elsewhere in the URL can be visually distracting. The generic URI syntax standardized in RFC 3986 is the foundation for interpreting those components.

More detail

Can I Share This? rejects non-HTTP(S) destinations and credential-bearing URLs. It also checks structural signals such as direct IP-address hosts, punycode, unusually deep subdomains, uncommon ports, heavy percent-encoding and very long URLs. None of those signals alone proves abuse.

2. Resolve the destination and follow redirects

The address shown in a message is not always the address that ultimately loads. URL shorteners, analytics platforms, authentication systems and malicious redirectors can all send a browser through one or more intermediate URLs.

More detail

The scanner follows a bounded redirect chain and records destination changes. It then highlights the final hostname so the user can compare it with the service or organization they expected. A domain change is context, not an automatic verdict: legitimate services also redirect between domains.

3. Inspect the response without using your signed-in browser session

The quick scan requests the destination from the server side rather than opening it inside the user's authenticated browser. It can inspect basic response metadata, identify certain forced downloads or binary responses, and look for simple signs that a page is asking for authentication.

More detail

This separation is important. A server-side check does not inherit the user's cookies or logged-in state, so it cannot reproduce every personalized page or account-specific flow. Dynamic content can also vary by geography, device, time or request headers.

4. Combine signals instead of relying on one rule

Useful detection is multi-signal. A shortened URL is common and often legitimate. A login page is common and often legitimate. A redirect is common and often legitimate. Risk becomes more meaningful when independent signals reinforce one another, such as a brand-lookalike hostname combined with account-verification wording and an unexpected executable download.

More detail

Can I Share This? converts observed warning signs into a risk score and plain-language status. The score is not a probability that a site is malicious. It is a summary of the signals found during that scan.

5. Keep structural checks separate from reputation checks

A reputation service asks whether a URL or destination is already known to threat-intelligence systems. That is different from examining the structure and behavior of the link itself. New malicious pages can exist before reputation databases have seen them.

More detail

Can I Share This? keeps the optional reputation lookup separate because private sharing links may contain access tokens or sensitive query parameters. The quick scan does not pretend that a URL was checked against every external threat database when it was not.

What a scanner cannot prove

A scanner cannot guarantee that a page will remain unchanged, that a download contains no previously unknown malware, or that the person who sent the link is trustworthy. It also cannot infer business legitimacy from URL structure alone.

More detail

For unexpected requests involving passwords, one-time codes, payment details, identity documents or recovery phrases, verify the destination independently even when the technical result appears low risk.

Primary references

These references define or document the web and security concepts discussed above.

Last reviewed: September 2, 2026.

Related reference pages

Check a suspicious link

Use the scanner to inspect the URL, redirects and final destination before you open it.

Analyze the link

What happens when CanIShareThis scans a link

  1. Normalize the input. The scanner parses the submitted URL and identifies the hostname, protocol, path, query parameters, and recognizable platform patterns.
  2. Inspect the URL structure. It looks for suspicious formatting, deceptive hostname patterns, unusual encodings, risky parameters, and other structural warning signals.
  3. Follow destination signals. When a network check is available, the scanner evaluates redirects and exposes the final destination so a shortened or wrapped link is easier to understand.
  4. Evaluate domain context. Domain and reputation signals are combined with the URL structure rather than treated as a single yes/no blacklist result.
  5. Inspect content context when supported. Download links, cloud-sharing links, social profiles, and other recognizable inputs can receive additional checks relevant to that type.
  6. Return a risk-oriented result. The result summarizes the strongest signals and a recommended action instead of claiming that a link is guaranteed safe.

Signals are combined, not treated as proof

No single signal is sufficient on its own. HTTPS does not prove legitimacy. A new domain is not automatically malicious. A clean reputation lookup does not guarantee that a page is harmless. Redirects are not inherently dangerous. The scanner combines available evidence and keeps uncertainty visible.

URL structure

Hostname, subdomains, encoding, suspicious terms, sensitive parameters, and recognizable destination patterns.

Redirects

Intermediate and final destinations when they can be resolved safely.

Reputation

External or internal reputation signals when configured and available.

Lookalikes

Domain patterns that can resemble known brands or expected destinations.

Privacy

Tracking and sensitive URL parameters that may expose unnecessary information.

Type-specific checks

Additional logic for supported link contexts rather than a one-size-fits-all verdict.

Limits of a link scanner

A website can change after a scan, serve different content to different visitors, or use legitimate infrastructure for malicious purposes. Some pages also require authentication and cannot be fully inspected from outside the recipient’s account.

The scanner is decision support, not a guarantee. If a result conflicts with the context of a message, payment request, login prompt, or unexpected contact, verify through an independent trusted channel.

See also Methodology, Security, Privacy, and Supported checks.