How fast is a Linkbreakers scan? Latency, and what happens in it

Short answer

A Linkbreakers scan answers in a median of 65ms of server time, measured on production scans. Three quarters of scans answer within 77ms.

That number covers more than a redirect. In those milliseconds Linkbreakers finds the link, recognises whether this visitor has scanned before, evaluates the link's workflow (country, device, time of day, visit type and other conditions), and decides where the visitor goes next: a destination, a form, a contact card or another page.

What happens during a scan

Most link shorteners look a slug up and redirect. A Linkbreakers scan runs a workflow:

1. Find the link, including on custom domains.
2. Recognise the visitor, so the same phone scanning three QR codes at one event is one visitor, not three.
3. Understand the visit: location, device, operating system, browser and language, and whether it comes from a person, a crawler or an AI agent (GPTBot, ClaudeBot and similar).
4. Run the workflow: conditions on country, device, time, day, date, visit type or visitor data route the visitor through the steps you built.
5. Answer: send the visitor to the destination, or show the form, contact card, social links page or thank you page.
6. Record it: the visit, each step completed, and the webhooks and integrations that listen for them.

Why it is fast

• Built for the scan. The path a scan takes is designed and tuned in-house for one job: getting a person from a printed code to the right place.
• Your visitor goes first. Anything that does not have to happen before the visitor moves on happens after. Nothing is skipped; the visitor simply never waits for it.
• Popular links are ready before they are scanned. Codes that are scanned often answer without extra work, and any change you make still applies to the very next scan.
• Headroom for bursts. When a crowd scans the same poster at once, every person is answered just as fast and recorded as their own visit, on their own device.

Workspaces that choose advanced data collection also read details from the visitor's browser. That needs a page to load first, so those scans take one more round trip by design.

How we measure

• What: server time for successful scans, from the moment the request reaches Linkbreakers to the moment the answer is sent.
• Which scans: real scans of existing links. Requests for addresses that do not exist are excluded, because they answer almost instantly and would make the numbers look better than a real scan.
• Not included: the network between the visitor and our servers, which depends on where the visitor is and on their connection.

How this compares

Published response times

These are the figures we found published for each product. They are not all measured the same way, so the "Measured how" column matters as much as the number.

Product	Published figure	Measured how	Source
Linkbreakers	65ms median	Server time, real production scans, running a full workflow	This article
Bitly	"Tens of milliseconds"	Server processing time, stated by Bitly	Bitly Support
Bitly	91ms average	Load test of 40,000 requests, location not stated	once.to performance comparison
Rebrandly	100ms average	Same load test as above	once.to performance comparison
Short.io	50ms average	Stated by Short.io for its enterprise network	Short.io Enterprise page
Dub	30 to 80ms median	Range given for edge-hosted shorteners as a group, not Dub alone	u2l.ai speed test
TinyURL	100 to 250ms median	Range given for older shorteners as a group	u2l.ai speed test
QR Code Generator, Uniqode, QR TIGER, Flowcode	None published

Two things to keep in mind when reading this table. Most third-party figures are published by competing link shorteners, and every product except Linkbreakers is timing a plain redirect. A Linkbreakers scan does the full list above in comparable time.

What each product does per scan

A plain redirect has less to do than a workflow. Here is what each product documents doing per click or scan.

Product	Per-scan data documented	Conditional routing	Multi-step flows	Same visitor across links
Linkbreakers	Location to city, ISP, device, OS, browser, language, human/bot/AI agent, optional browser hardware	Country, device, time, day, date, visit type, visitor data	Yes: forms, conditions, contact cards, pages	Yes, across a workspace
Bitly	Country, city, device, referrer (city and device on Premium)	Country and platform (Growth+), region and device (Premium+)	Not documented	Not documented
Dub	Country, region, city, device, browser, OS, referrer	Geo, device, A/B	Not documented	Conversion attribution cookie
Short.io	Country, city, browser, OS, referrer	OS, country, city, A/B	Not documented	Not documented
Rebrandly	Location to coordinates, device, browser, OS, language, bot flag	Up to 10 rules (device, OS, location, language, date)	Not documented	Short-lived session hash
QR Code Generator	Scans over time, OS, country, city	Location, device, time (blog)	Not documented	Not documented
Uniqode	Location (GPS opt-in), device, OS, browser, time	Smart Rules, up to 11	Lead forms	Not documented
QR TIGER	Device, country, city, local time	Location, time, language, scan count	Not documented	Not documented
Flowcode	Date and time, device, location (precise needs opt-in)	Device, day, time, location (USA)	Contact collection form	Pixel session id

None of these products documents detecting AI agent traffic as its own category.

Limits and caveats

• The median is measured on recent production scans.
• Server time excludes the visitor's network, which is usually the larger share of what they wait.
• Advanced data collection needs the browser, so those scans take one round trip more than basic ones.
• Published response times come from different methods and locations, and most are not independent. They are shown as published, not re-measured.
• The comparison tables reflect each vendor's public pages. Products change; check each vendor's current docs.

Frequently asked questions

Does speed mean less is recorded?

No. Every scan records the visit, the steps completed and the webhooks. The visitor simply never waits for the recording to finish before being sent on.

Why is the latency card linked to server time rather than end-to-end time?

Server time is the part we control and can measure for every scan. End-to-end time depends mostly on the visitor's network and location.

Do workflows with conditions take longer?

No meaningful difference. A chain of conditions adds very little to a scan. Forms and other pages take as long as the page they show.

Sources

• Linkbreakers request logs
• Bitly response time: https://support.bitly.com/hc/en-us/articles/360059652971-What-is-the-response-time-latency-when-opening-a-Bitly-Link
• once.to performance comparison (Bitly, Rebrandly): https://docs.once.to/en/about/performance-comparison/
• Short.io Enterprise: https://short.io/enterprise
• u2l.ai URL shortener speed test (Dub, TinyURL ranges): https://u2l.ai/tools/url-shortener-speed-test
• Bitly pricing and features: https://bitly.com/pages/pricing
• Dub analytics: https://dub.co/help/article/dub-analytics and attribution: https://dub.co/docs/concepts/attribution
• Short.io metrics: https://docs.short.io/articles/statistics/short.io-metrics/what-do-statistics-metrics-mean.md and pricing: https://short.io/pricing
• Rebrandly click events: https://developers.rebrandly.com/docs/click-events and link rules: https://developers.rebrandly.com/docs/advanced-link-options
• QR Code Generator analytics: https://support.qr-code-generator.com/hc/en-us/articles/7665807665933
• Uniqode analytics: https://docs.uniqode.com/en/articles/9305836-introduction-to-qr-code-analytics and Smart Rules: https://docs.uniqode.com/en/articles/8494786-create-condition-based-qr-codes-using-smart-rules
• QR TIGER tracking: https://www.qrcode-tiger.com/qr-code-tracking
• Flowcode analytics: https://support.flowcode.com/what-analytics-are-included-with-flowcode-pro-and-pro-go-to-flowcode and Smart Rules: https://help.flowcode.com/en/articles/6927436-how-to-add-smart-rules-to-your-flowcode