You cannot click safely on what you cannot see. Every phishing attack that disguises a link relies on the same blind spot: the words you read are not the address you visit. The display text says one thing; the href goes somewhere else entirely. By the time you would normally find out, you have already clicked. And it is not always a crude look-alike domain: often the link routes through a tracker or redirector, so where you actually land is nothing like the brand named in the text.
Hovering to inspect a URL helps, but it is voluntary, easy to skip, awkward on mobile, and — even when you do it — it asks you to read a long address and pick out the one part that matters. That is a lot to ask on every link, every day. Reveal URLs removes the effort: it makes the real destination visible by default, so the mismatch jumps out instead of hiding.
The link that looks right but isn't
Consider a real 2025 campaign against Booking.com. The email showed a link reading https://admin.booking.com/hotel/hoteladmin/… — exactly what a hotelier would expect. The address it actually pointed to was https://account.booking.comんdetailんrestric-access.www-account-booking.com/en/. The character between "com" and "detail" is not a slash: it is the Japanese hiragana ん (U+3093), which in many fonts renders almost identically to "/". The real registered domain is therefore www-account-booking.com — attacker-controlled — and everything to its left is just subdomain text dressed up to read like a path on booking.com.
This is the case Reveal URLs is built to defend against. Seeing the URL is necessary, but not always sufficient: you also have to recognise which part is the real registered domain. Reveal URLs puts the destination in front of you by default — printed above the link and flagged in red the moment its host does not match the name in the link text — so the mismatch does the work for you.
This is the client-side, practical answer to a problem we examined in depth earlier: why email authentication stops domain spoofing but not link-based phishing, and why the industry should always show the URL. For the full background, see Email link phishing: why your email app should always show the URL.
What Reveal URLs does
Reveal URLs compares the visible link text against the link's actual href and flags any mismatch. For every link it prints the real destination directly above the link, prefixed with → , inside a thin box. When the destination's host does not match the hostname named in the link text, that box and its text turn red; otherwise they stay a plain dark grey. The warning you need is there by default, before you click — no hover, no long-press.
Take a worked example. A message contains a link whose text reads amazon.com, but whose href points at https://amaz0n-secure.com/signin (a zero in place of the "o", on a domain nobody at Amazon owns). With Reveal URLs the gap is unmissable: above the link sits → https://amaz0n-secure.com/signin in a red box, because the destination host amaz0n-secure.com does not match the amazon.com the text promises. You see the deception before you click, with no hovering and no guesswork.
On the web and in Thunderbird, the WebExtension prints the destination above each link as the page or message is rendered. In Outlook, the same analysis appears in a side panel. Either way, the destination is visible by default — never hidden behind a hover or a long-press.
This is not hypothetical. Take a real parcel-delivery phishing email: it warns that a package is held until an outstanding customs charge is paid and offers a friendly “Go to payment” button whose label names no destination at all. Reveal URLs prints the button's true destination directly above it — → parcel-pay.custom.co.xa — so the address the friendly label hides is in plain sight. You can see where the button really leads, and you never had to click to find out.
How it works across platforms
Reveal URLs is a single idea delivered through whatever mechanism each platform allows. Underneath, every variant does the same thing: read the links, work out where they really go, and print that destination above the link — red when the destination host does not match the link text. Where that work happens differs by surface, so each is spelled out below.
- Browsers and Thunderbird (WebExtensions): on Chrome, Edge, Opera, Firefox, and Thunderbird, a content script post-processes the rendered DOM and prints each link's destination above it. These do all their work on your own device, transmitting nothing.
- Gmail (coming soon): a Google Apps Script add-on will show the same destination above each link inside the Gmail interface. Because Gmail add-ons run on Google's own servers, the open message will be read and analysed there (by Google, who already hold your mail), never by us and never by anyone else.
- Outlook (coming soon): an Office.js add-in will show the analysis in a side panel. Its task-pane UI will load from Codeberg Pages over HTTPS, but the link analysis itself will run locally on the message in front of you — no email or message data is sent anywhere.
- Safari: planned.
Reveal URLs ships with built-in support for the providers people are phished through most — Gmail, Outlook, and Proton Mail — and the host list is user-extensible from the options page, so you can add the webmail and sites you use. The interface is localized into many languages.
Seeing the real destination before you click
Privacy and no tracking
Where Reveal URLs does its work depends on the surface, and it is honest about the difference. The browser extensions and the Thunderbird add-on do all their work on your own device, transmitting nothing: nothing about the messages you read, the links you see, or the pages you visit ever leaves your machine. There are no analytics, no telemetry, and no tracking of any kind.
The Gmail add-on (coming soon) will be the exception. Because Gmail add-ons run on Google's own servers, the open message will be read and analysed there — by Google, who already hold your mail, never by us and never by anyone else.
Outlook (coming soon) will sit in between: the add-in's user interface will be served over HTTPS from Codeberg Pages (that is how Office add-ins are distributed), but the actual link analysis will still run locally on the message you are viewing, and no email or message data is sent anywhere. A security tool you cannot trust is worse than none, so Reveal URLs is precise about where each surface does its work rather than making one blanket promise.
Open source and license
Reveal URLs is free and open source, released under the AGPL-3.0-only license. The code is a TypeScript pnpm monorepo, and the project is © 2026 Jeroen Derks (Magentron). Because it is open source, you do not have to take any privacy claim on faith — you can read exactly what it does, build it yourself, and confirm for each surface where the analysis runs: on your own device for the browser extensions and Thunderbird, transmitting nothing.
The full source lives at codeberg.org/magentron/reveal-urls.
Install Reveal URLs
- Chrome Web Store (also for Brave, Opera, etc.)
- Microsoft Edge Add-ons
- Firefox Add-ons (AMO)
- Thunderbird Add-ons (ATN)
On Opera, install the Chrome build from the Chrome Web Store; a dedicated Opera listing is coming soon.
Coming soon: the Gmail add-on (Google Workspace Marketplace) and the Outlook add-in (Microsoft AppSource).
Project page: magentron.codeberg.page/reveal-urls · Source code: codeberg.org/magentron/reveal-urls
Reveal URLs is the practical, client-side answer to a problem we argued in depth in Email link phishing: why your email app should always show the URL: email authentication can prove who sent a message, but not where its links go. Until clients show the URL by default, this fills the gap — free, open source, and honest about where each surface does its work.