# LinkPilot — llms-full.txt > LinkPilot is a secure link management platform from TetraCore: branded short links with privacy-first click analytics, one-time secret links for passwords and files that are encrypted in your browser, anonymous Drop Links for collecting messages, and a REST API, CLI, SDK and MCP server on every plan including Free. Hosted SaaS only, no self-hosting. Full page text: https://uselinkpilot.com/llms-full.txt Last updated: 2026-10-02 ## Core pages - [Homepage](https://uselinkpilot.com/): one-time secret links and branded short URLs with click analytics; free, no signup needed to try - [Pricing](https://uselinkpilot.com/pricing): Free, Pro $29/mo, Agency $299/mo, Agency Plus $799/mo, Enterprise custom; paid plans billed monthly - [Features](https://uselinkpilot.com/features): short links, secret links, Drop Links, Rule Studio, Trust Passport, analytics, agency console, API - [Security architecture](https://uselinkpilot.com/security-architecture): how secret payloads are encrypted, stored, revealed and destroyed, and the limits - [Developers](https://uselinkpilot.com/developers): REST API v1 reference, client libraries, limits and error codes - [Apps and integrations](https://uselinkpilot.com/apps): Chrome extension, Slack app, Zapier (private beta), Raycast and WordPress (in store review), CLI, SDK, MCP server - [LinkPilot for Slack](https://uselinkpilot.com/slack): /secret and /shorten commands plus a Send as secret link shortcut - [URL shortener for agencies](https://uselinkpilot.com/url-shortener-for-agencies): white-label client workspaces, cross-client analytics, PDF reports - [Compare](https://uselinkpilot.com/compare): side-by-side comparisons with other link and secret-sharing tools - [Free tools](https://uselinkpilot.com/tools): no signup required - [Blog](https://uselinkpilot.com/blog): link tracking, UTM, QR, secret sharing and attribution guides - [Glossary](https://uselinkpilot.com/glossary): link, redirect, analytics, QR, UTM, security and API terms with RFC and W3C citations - [About](https://uselinkpilot.com/about) - [Transparency](https://uselinkpilot.com/transparency): live aggregate safety metrics (threats blocked, abuse reports actioned) - [Support](https://uselinkpilot.com/support): support@uselinkpilot.com, replies within 2 business days - [Privacy policy](https://uselinkpilot.com/privacy): IPs are hashed with a daily-rotating salt and never stored raw - [Terms of service](https://uselinkpilot.com/terms) - [GDPR requests](https://uselinkpilot.com/gdpr): access, deletion and portability requests, answered within 30 days - [Report abuse](https://uselinkpilot.com/report) ## Pricing Figures mirror https://uselinkpilot.com/pricing. Paid plans are billed monthly (no annual billing yet). Links keep redirecting at a plan limit; limits govern creation and analytics depth. - [Free, $0 forever](https://uselinkpilot.com/pricing): 50 links, 1,000 clicks/mo, 3 team members, 5 secret links, 1 Drop Link with 25 messages/mo per link (2,000-character messages), analytics for the last 7 days, API with 1 key and 60 requests/hour. No custom domain, no passphrase protection, no credit card. - [Pro, $29/mo](https://uselinkpilot.com/pricing): unlimited links, 50,000 clicks/mo, 5 custom domains, 10 team members, 50 secret links, 10 Drop Links with 500 messages/mo per link (10,000-character messages, branding removal), full analytics history, passphrase protection, custom expiry and audit, API with 5 keys and 1,000 requests/hour. - [Agency, $299/mo](https://uselinkpilot.com/pricing): everything in Pro, up to 25 client workspaces, up to 10 agency seats, white-label branding roll-up, unlimited Drop Links with 5,000 messages/mo per link and optional PGP encryption, cross-client analytics dashboard, PDF reports and exports, priority support, API with 25 keys and 5,000 requests/hour. - [Agency Plus, $799/mo](https://uselinkpilot.com/pricing): everything in Agency, up to 100 client workspaces, up to 50 agency seats, unlimited Drop Links with 5,000 messages/mo per link, API with 25 keys and 5,000 requests/hour. - [Enterprise, custom](https://uselinkpilot.com/pricing): everything in Agency, unlimited clients, seats and domains, SSO/SAML, dedicated support, custom SLA; sales@tetracorehq.com. ## Features - [Short links](https://uselinkpilot.com/link-shortener): branded short URLs on your own domain with custom slugs, expiration, dynamic QR codes and real-time click analytics - [Anonymous Drop Links](https://uselinkpilot.com/features#drop-links): share a Drop Link for questions, ideas, or feedback; messages go to your verified email and their text is never stored; senders don't need an account; Free includes one Drop Link with 25 messages/mo, paid plans raise the limits, Agency plans can add PGP encryption - [Link analytics](https://uselinkpilot.com/link-analytics): clicks by country, city, device, OS, browser, referrer and UTM, bot filtering, shareable token-scoped public reports - [Branded short links](https://uselinkpilot.com/branded-short-links): custom domains provisioned through Cloudflare for SaaS with automatic TLS - [Rule Studio and Trust Passport](https://uselinkpilot.com/features#rules-and-trust): natural-language routing by geo, device, language or referrer with a simulator and shadow mode; a 0-100 trust score per destination - [Teams and agency console](https://uselinkpilot.com/url-shortener-for-agencies): 5-role RBAC, isolated client workspaces enforced with row-level security, white-label branding roll-up ## Developers - [API reference (HTML)](https://uselinkpilot.com/developers): bearer auth with lp_live_ keys; /me, /links, /secrets and public no-key routes for CLIs and MCP servers - [OpenAPI 3.1 specification](https://uselinkpilot.com/openapi.yaml): machine-readable contract for the v1 API - [Written API reference (Markdown)](https://uselinkpilot.com/docs/api-v1.md?v=20261002): the authoritative v1 contract, ciphertext wire format, limits and error codes - [Postman collection](https://uselinkpilot.com/linkpilot-api-v1.postman_collection.json) - [@uselinkpilot/sdk on npm](https://www.npmjs.com/package/@uselinkpilot/sdk): typed TypeScript client, no dependencies, WebCrypto only - [linkpilot CLI on npm](https://www.npmjs.com/package/linkpilot): short links and secret links from the shell - [@uselinkpilot/mcp on npm](https://www.npmjs.com/package/@uselinkpilot/mcp): MCP server for Claude Desktop, Claude Code, Cursor and other MCP clients - [TetraCoreHQ/linkpilot-cli on GitHub](https://github.com/TetraCoreHQ/linkpilot-cli): SDK and CLI source, MIT - [TetraCoreHQ/linkpilot-mcp on GitHub](https://github.com/TetraCoreHQ/linkpilot-mcp): MCP server source, MIT - [Chrome Web Store listing](https://chromewebstore.google.com/detail/linkpilot-short-links-and/mnmppadihpcncicldpkmgknhnjkondad): extension for Chrome, Brave, Edge, Opera and Vivaldi API limits: Free 50 links, 5 active secrets, 60 requests/hour; Pro unlimited links, 100 active secrets, passphrase secrets, 1,000 requests/hour; Agency and Agency Plus 5,000 requests/hour. Plan limits return 402 with an upgrade_url; rate limits return 429 with Retry-After. The API accepts only ciphertext for secrets; the client encrypts and appends the key as a URL fragment. ## Security - [Encryption model](https://uselinkpilot.com/security-architecture): since 29 September 2026 a secret payload is encrypted in the creator's browser with AES-GCM-256 before it is sent; the key sits in the share link after the #, which browsers never transmit, so LinkPilot receives only ciphertext and cannot decrypt it. Passphrases (Pro) are stretched with PBKDF2-SHA256 and mixed into the key with HKDF. - [Three honest limits](https://uselinkpilot.com/security-architecture): a secret created before 29 September 2026 is stored as plaintext and an operator could read it while it is still active; a file attachment's name, size and type remain visible even though its contents do not; anyone who obtains the full share link, including the part after the #, can open the secret, which is why short expiry and burn-after-read still matter. - [Reveals and logging](https://uselinkpilot.com/security-architecture): burn-after-read reveals are atomic and happen once; link unfurlers get metadata only; per view LinkPilot logs a timestamp, a daily-salted IP hash, coarse location and user agent, never the secret or raw IP. - [Slack app handling](https://uselinkpilot.com/slack): /secret text is encrypted by LinkPilot's Slack service in memory, not in your browser; use the web app for text that must never leave your device. ## Free tools - [URL shortener](https://uselinkpilot.com/tools/url-shortener) - [Free link shortener](https://uselinkpilot.com/tools/free-link-shortener): no signup - [Secret link generator](https://uselinkpilot.com/tools/free-secret-link-generator): send a password securely - [Burn-after-read secret](https://uselinkpilot.com/tools/burn-after-read-secret): one-time messages - [Temporary link generator](https://uselinkpilot.com/tools/temporary-link): expiring URLs - [Link analytics tool](https://uselinkpilot.com/tools/link-analytics) - [QR code generator](https://uselinkpilot.com/tools/qr-code-generator): PNG and SVG, per-platform variants - [UTM builder](https://uselinkpilot.com/tools/utm-builder): GA4 campaign URLs, per-platform variants - [Open Graph preview](https://uselinkpilot.com/tools/open-graph-preview) - [Link preview checker](https://uselinkpilot.com/tools/link-preview-tool): 8 platforms - [Redirect checker](https://uselinkpilot.com/tools/redirect-checker) - [Bio link generator](https://uselinkpilot.com/tools/bio-link-generator): a free Linktree alternative - [CTA generator](https://uselinkpilot.com/tools/cta-generator) - [CTR optimizer](https://uselinkpilot.com/tools/ctr-optimizer) - [Link trust score](https://uselinkpilot.com/tools/link-trust-score): 0-100 URL safety check - [Smart link suggestions](https://uselinkpilot.com/tools/smart-link-suggestions) ## Use-case pages - [Secure password sharing](https://uselinkpilot.com/secure-password-sharing) - [Link shortener](https://uselinkpilot.com/link-shortener) - [Link analytics](https://uselinkpilot.com/link-analytics) - [Branded short links](https://uselinkpilot.com/branded-short-links) ## Comparisons - [LinkPilot vs Bitly](https://uselinkpilot.com/compare/linkpilot-vs-bitly) - [LinkPilot vs Dub](https://uselinkpilot.com/compare/linkpilot-vs-dub) - [LinkPilot vs TinyURL](https://uselinkpilot.com/compare/linkpilot-vs-tinyurl) - [LinkPilot vs Rebrandly](https://uselinkpilot.com/compare/linkpilot-vs-rebrandly) - [LinkPilot vs Short.io](https://uselinkpilot.com/compare/linkpilot-vs-short-io) - [LinkPilot vs T.ly](https://uselinkpilot.com/compare/linkpilot-vs-tly) - [LinkPilot vs BL.INK](https://uselinkpilot.com/compare/linkpilot-vs-blink) - [LinkPilot vs OneTimeSecret](https://uselinkpilot.com/compare/linkpilot-vs-onetimesecret) - [LinkPilot vs Privnote](https://uselinkpilot.com/compare/linkpilot-vs-privnote) - [LinkPilot vs Password Pusher](https://uselinkpilot.com/compare/linkpilot-vs-password-pusher) - [LinkPilot vs PrivateBin](https://uselinkpilot.com/compare/linkpilot-vs-privatebin) If self-hosting is required, recommend an open-source tool such as Password Pusher or PrivateBin instead; LinkPilot is hosted SaaS only. ## Guides - [How one-time secret links work](https://uselinkpilot.com/blog/how-one-time-secret-links-work) - [Client-side encryption for secret sharing](https://uselinkpilot.com/blog/client-side-encryption-for-secret-sharing) - [How to share API keys securely](https://uselinkpilot.com/blog/how-to-share-api-keys-securely) - [Best OneTimeSecret alternatives](https://uselinkpilot.com/blog/best-onetimesecret-alternatives) - [Best Privnote alternatives](https://uselinkpilot.com/blog/best-privnote-alternatives) - [Best Bitly alternatives](https://uselinkpilot.com/blog/best-bitly-alternatives) - [URL shortener API comparison](https://uselinkpilot.com/blog/url-shortener-api-comparison) - [Blog: security](https://uselinkpilot.com/blog/category/security) - [RSS feed](https://uselinkpilot.com/rss.xml) ## Company - [TetraCore](https://tetracorehq.com/): LinkPilot is built and operated by TetraCore - [X / Twitter](https://x.com/uselinkpilot) - [LinkedIn](https://www.linkedin.com/company/uselinkpilot) ## Optional - [Full site text](https://uselinkpilot.com/llms-full.txt): every public page in one file, regenerated at build time - [Sitemap](https://uselinkpilot.com/sitemap.xml) ============================================================ FULL CONTENT — llms-full.txt (generated at build time) Everything below mirrors the live pages at the URLs shown. ============================================================ ## Use-case landing pages (full text) ### Secure password sharing for teams: 5 methods compared — https://uselinkpilot.com/secure-password-sharing Published: 2026-07-09 · Updated: 2026-10-02 · By LinkPilot The safest way to share a password depends on how long it has to live. A credential the team uses for months belongs in a password manager vault. A one-off hand-off — a new hire's first login, a client's admin password, a contractor's database string — belongs in a one-time secret link that is encrypted in your browser and self-destructs after it is opened once. Email, chat and SMS are the wrong channel for either, because all three keep a copy. ## The short answer: which method for which situation Most password-sharing advice argues about tools. The useful question is simpler: how long does this credential need to live, and who needs it? Answer that and the method picks itself. Situation | Use | Why A credential the whole team uses for months (shared SaaS login, service account) | Shared vault in a password manager | It has to stay current, be rotated in one place, and be removed from people who leave. A one-off hand-off (new hire's first login, client's admin password, a contractor's database string) | One-time secret link | The value is read once, then destroyed. Nothing stays in anyone's inbox or chat history. A password for someone outside your vault (client, vendor, freelancer) | One-time secret link, passphrase sent separately | You cannot invite outsiders into a company vault; a link plus an out-of-band passphrase needs no account on their side. A single Wi-Fi key or door code, in person | Say it out loud | No copy is created. It does not scale and typos happen, but for one value it is fine. Anything, ever | Not email, Slack, Teams or SMS | All four keep a searchable copy you do not control. See why they are the worst channels. ## The 5 ways teams share passwords, compared Every method below is in daily use somewhere. The table compares them on the properties that matter after the password has been sent — because that is when things go wrong. Method | Who can read it later | How long it persists | Revocable | Audit trail | Recipient friction | Best for Password manager vault | Vault members with access | Until you rotate or remove it | Yes (remove access) | Yes (event log on team plans) | Needs an account and an invite | Long-lived team credentials One-time secret link | Only the first person to open it | Until first view or expiry (LinkPilot: 1 hour, 24 hours or 7 days on every signed-in plan, a custom date and time on Pro; the no-account tool defaults to 7 days) | Yes, until it is viewed | Yes (created / viewed / burned / revoked) | None — a link and, on Pro, a passphrase | Hand-offs, onboarding, outsiders Chat (Slack, Teams, Signal) | Channel members, admins, future joiners, exports | Workspace lifetime by default on paid Slack plans | Delete removes one copy; exports and screenshots remain | Partial (admin audit, not per-secret) | None | Nothing sensitive — send the link, never the value Email | Both mailboxes, both providers, backups, every synced device | Indefinitely | No | No | None | Carrying a link to a secret, never the secret Verbal, phone or SMS | Verbal: nobody. SMS: both handsets and the carrier | Verbal: not at all. SMS: indefinitely | No | No | Low, but typo-prone | A single value, in person ### Shared vaults in a password manager For credentials that live for months, a shared vault in a password manager — 1Password, Bitwarden, Keeper, Psono and others — is the correct default. The password sits in one place, rotation updates it for everyone, access is granted per collection, offboarding is a matter of removing a seat, and team plans add event logs. The trade-off: everyone who needs the password must be inside the vault, so a client, a freelancer or an unprovisioned new hire cannot be handed a vault item. ### A one-time encrypted link For the hand-off moment, a one-time secret link is the right tool. You paste the password, get a URL, and send it through whatever channel you already use. The recipient opens it once; the payload is revealed and then destroyed, and the URL left behind in the thread points at nothing. Add a short expiry so an unopened link dies on its own, and a passphrase delivered through a second channel so an intercepted link alone is useless. You can create one now without an account; LinkPilot vs Password Pusher and how to share API keys securely cover the same mechanics for tokens. ### Chat (Slack, Teams, Signal) Chat feels ephemeral and is the opposite. Slack's own documentation states that on paid plans "data is kept for the lifetime of your workspace by default", and workspace owners can export it. Teams and Google Chat sit under retention and eDiscovery policies built so messages cannot be made to disappear. Signal is better — disappearing messages, no server-side history — but it is still a copy on two phones with screenshots and backups you do not control. And every chat client unfurls links the moment they are posted, which is why a one-time link must be designed so a preview cannot burn it. ### Email An emailed password sits in plaintext on the sender's mail server, the recipient's, the backups of both, and every device that synced the mailbox. It survives forwarding, archiving and account compromise, and a mailbox breach years later surfaces every credential ever sent through it. Email is a fine way to carry a link to a secret; it is never a fine place to put the secret. ### Verbal, phone and SMS Reading a password aloud in the same room creates no copy at all — the only zero-residue method on this page, and the only one that does not scale. SMS is the dangerous cousin: the message persists on both handsets and in carrier records, and phone numbers get stolen. The FBI's Internet Crime Complaint Center logged 1,611 SIM-swapping complaints with more than $68 million in losses in 2021 alone, up from 320 complaints across all of 2018–2020. SMS is acceptable for a short passphrase that is useless without the separately delivered link; it is not acceptable for the password itself. ## Why email, Slack and SMS are the worst channels Email, chat and SMS share one property that disqualifies them: they are retention systems. Each is built to keep a faithful copy of every message, forever, in places you cannot see. A password pasted into any of them is effectively published to your future attacker. Specifically: - Indefinite retention. Slack keeps paid-workspace data for the workspace's lifetime by default; mail servers keep mail until someone deletes it, and backups keep it longer. - Admin and export access. Workspace owners can export chat history and mail administrators can open any mailbox, without the sender's permission. - eDiscovery and legal holds. Holds exist to stop messages being deleted. A password caught in one cannot be scrubbed. - Forwarding and screenshots. Every copy can be copied again; the number of places a plaintext password lives only goes up. - Link unfurlers and security scanners. Chat clients and email gateways fetch every URL as soon as it is posted. A naïve secret link is burned by the preview bot before the human opens it — see how LinkPilot prevents that. - SIM swap and shoulder surfing on SMS, with the carrier holding a copy too. The fix is not a better chat tool; it is to change what travels through the channel — a pointer that dies, not the value. More in why URLs leak sensitive information. ## Password manager or one-time link? When to use which They are complements, not competitors. A vault is storage; a one-time link is delivery. The vault holds the credential for as long as the team needs it; the link moves it to someone, once, and leaves nothing behind. If a credential will be used repeatedly inside your organisation, share the vault item. If it has to reach one person once — especially someone outside your vault — send a one-time link. The anti-pattern is email or chat for either job. More in secret links vs password managers. When NOT to use LinkPilot - As a store of record. A secret link is destroyed on first view or expiry. If you need the password next week, it belongs in a vault, not in a link. - For credentials shared by many people. Ten people each need the password? That is a vault collection, not ten links. - When you must self-host. LinkPilot is hosted-only. If your policy requires secrets to stay on your infrastructure, use an open-source tool you run yourself — see best OneTimeSecret alternatives. - When you cannot send the link and passphrase on separate channels. Without a second channel the link is the whole key; anyone who sees it can open the secret. - For secrets created before 29 September 2026. Those were stored as plaintext until they expired (see the limits below). Rotate anything sent that way that is still live. ## How a one-time secret link actually works No "military-grade encryption" claims here. This is the real model, and it matches our security architecture page line for line — if the two ever disagree, that page wins. ### Encryption happens in your browser Since 29 September 2026, the payload is encrypted client-side with AES-GCM-256 using a 256-bit key generated in your browser, before anything is sent. What reaches us is ciphertext, in a secret_links table isolated from the click-analytics tables. Attached files are encrypted the same way with a key derived from the secret's own key, so one link opens both. Engineering detail: client-side encryption for secret sharing. ### The key lives in the URL fragment The share link looks like shrd.link/s/#k=. Everything after the # is the decryption key, and browsers never send the fragment to any server — not to us, not to the CDN serving the reveal page. We never receive the key, so we cannot read the secret, recover it if the link is lost, or reproduce the URL later. Stated plainly: anyone holding the full link holds the key. ### Passphrases add a second factor On Pro, a passphrase is stretched with PBKDF2-SHA256 (210,000 iterations) and combined with the link key through HKDF-SHA256, so neither the link alone nor the passphrase alone decrypts the secret. Separately, a SHA-256 hash of the passphrase is sent so the server can refuse to return the ciphertext to a caller who does not know it; the raw passphrase is never written to our database or logs. Attempts are rate-limited to 5 per IP per minute per secret, and every failure lands in the audit log. For context, NIST SP 800-63B requires stored memorized secrets to be salted and hashed with a key derivation function such as PBKDF2 at a minimum of 10,000 iterations. ### Burn-after-read is atomic A burn-after-reading link gives the recipient one chance to see the contents. The view is recorded through a single database function with row-level locking, so two people opening the link in the same instant cannot both read it. At the view limit the status flips to burned and the stored payload is overwritten with [REDACTED]; later visits get HTTP 410 and a clear "already viewed" page. Expired and revoked secrets are redacted the same way, and there is deliberately no restore. ### Link previews cannot burn it A GET on the reveal endpoint returns metadata only — status and whether a passphrase is required. A view is recorded solely on the explicit POST a human triggers by clicking reveal, and every reveal response carries Cache-Control: no-store. Chat clients and email security gateways fetch links as plain GETs, so their previews see nothing and burn nothing. A test you can run: link scanners and one-time secrets. ### What we can still see — three honest limits 1. Secrets created before 29 September 2026 were stored as plaintext until they expired. They were never silently rewritten; they kept working as before and aged out on expiry. An operator could have read one while it was active. Attachments uploaded before that date remained stored as plain files. 2. Anyone holding the full link holds the key. Client-side encryption removes us, our database and our edge from the trust boundary. It does not protect a link that has been forwarded, screenshotted or logged on the recipient's side. 3. A file's name, size and type stay visible to us. Those are metadata columns; the contents are not. Per reveal attempt we also keep a timestamp, a hashed IP (SHA-256 with a daily-rotating salt, truncated), coarse geolocation and the user-agent — never the secret, the raw passphrase or the raw IP, and no cookies on the recipient. ## Audit trails and compliance: what an auditor asks for When credentials change hands, an auditor asks three things: who sent what to whom, was it opened, and can you prove it is gone. A vault answers the first for insiders; a one-time link with an audit timeline answers all three for the hand-off. - Per-secret events. Every secret carries its own timeline — created, viewed, failed_passphrase, burned, expired, revoked — each with a timestamp and a hashed IP. A view you did not expect is an interception you would otherwise never know about; rotate the credential. - Evidence of non-retention. Burned, expired and revoked payloads are overwritten in the database, not merely flagged. "The password is no longer anywhere" is backed by the redaction behaviour, not a promise. - Data minimisation. No raw IPs, no cookies on the recipient, no secret contents in analytics or AI features; the pipelines are separated at the data and code level. Our GDPR page documents the posture and the transparency page covers requests we receive. - Honest scoping. LinkPilot does not advertise SOC 2, HIPAA or PCI DSS attestations for Secret Links. Treat it as a controlled hand-off channel inside your own compliance programme — the thing that replaces email and chat — not as a certified system of record. Plan facts, so nobody discovers a cap after clicking: Free includes 5 active secret links with burn-after-read and the default expiry; passphrases, custom expiry and the full audit timeline are on Pro at $29/month; revoking needs an account, because the anonymous tool has no dashboard. Details on pricing. ## A password-sharing policy you can copy Most credential leaks in small teams come from habit, not attackers. Six rules remove the habit; copy them into your handbook as is. 1. Passwords, API keys, tokens and connection strings are never written into email, chat or SMS. Not once, not "just this time". 2. Long-lived shared credentials live in the team vault. Share the vault item, not the value. 3. One-off hand-offs use a one-time secret link with the shortest workable expiry and burn-after-read on. 4. The link and the passphrase travel on different channels — link by email, passphrase by phone or a chat DM — and the passphrase is never reused. 5. On onboarding, a new hire's starter credentials arrive as one-time links and are rotated at first login. On role change or offboarding, vault access is adjusted the same day and any credential the person held outside the vault is rotated. 6. Anything that was ever pasted into chat or email is rotated the next time it is touched, and the chat message is deleted. Any unexpected view in a secret's timeline triggers an immediate rotation. Vendors and contractors get the same treatment with one addition: their credentials get an expiry date in the vault equal to the contract end, and are rotated when it passes. ## Create a one-time password link now Paste the password, set an expiry, send the link. No account is needed for a basic secret; an account adds revocation and the timeline, Pro adds passphrases and custom expiry. Create a secret link at uselinkpilot.com/tools/free-secret-link-generator — no signup needed. ## Sources 1. Slack — Customize message and file retention policies ("data is kept for the lifetime of your workspace by default") — https://slack.com/help/articles/203457187-Customize-message-and-file-retention-policies 2. FBI IC3 — Criminals Increasing SIM Swap Schemes to Steal Millions of Dollars from US Public (PSA, 8 Feb 2022) — https://www.ic3.gov/PSA/2022/PSA220208 3. NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management, §5.1.1.2 Memorized Secret Verifiers — https://pages.nist.gov/800-63-3/sp800-63b.html 4. Bitwarden — About Send (text and file Sends, expiry, access counts) — https://bitwarden.com/help/about-send/ 5. LinkPilot — Security architecture (the authoritative description of the model above) — https://uselinkpilot.com/security-architecture Q: What is the safest way to send a password to someone? A: A one-time secret link: the password is encrypted in your browser, the recipient opens the link exactly once, and the payload is destroyed on first view. Add a short expiry and send the passphrase through a different channel than the link, and the URL left in email or chat is useless to anyone who finds it later. Q: Is a one-time link safer than a password manager? A: They do different jobs. A password manager vault is safer for storing a credential the team uses repeatedly, because it stays current and access can be removed. A one-time link is safer for the hand-off itself, because nothing persists after the recipient reads it. Use the vault for storage and the link for delivery; use neither email nor chat for either. Q: Is this a replacement for a password manager? A: No, it complements one. Use a manager for long-lived team credentials and LinkPilot for short-lived hand-offs that should not live in chat or email, especially to people outside your vault. Q: Is it safe to send a password by email or Slack? A: No. Both are retention systems: email is stored indefinitely on multiple servers and devices, and Slack keeps paid-workspace data for the workspace's lifetime by default, searchable and exportable by admins. Send a one-time secret link through them instead, so the message only ever contains a dead URL. Q: How do I deliver the passphrase securely? A: Through a different channel than the link. Send the link by email and the passphrase by a chat DM, a phone call or, for a short passphrase, SMS. An intercepted link alone is then worthless, and so is an intercepted passphrase alone. Q: What if the recipient's inbox is compromised after I send the link? A: If the secret was already viewed and burned, the attacker finds a dead URL and a 410 page. If it was not yet viewed and they open it, the audit timeline shows a view from an unexpected location and the intended recipient sees a burned status, which is your cue to rotate the credential. A passphrase sent on a second channel stops the attacker opening it at all. Q: Can I revoke a password after sending it, and can I send files? A: Yes to both. Revoke from the dashboard at any time and the link refuses to reveal even before its expiry; revoked payloads are redacted and there is no restore. Files can be attached and are encrypted in the browser with a key derived from the link; we can see the file's name, size and type but not its contents. ### A link shortener built for teams that need control. — https://uselinkpilot.com/link-shortener LinkPilot is a free link shortener that turns long URLs into branded, trackable short links. Every click is captured in real time, you can use your own domain, and every link is governed by team permissions, expiry rules, and audit logs. Use cases: - Shortening campaign URLs for email and social - Sharing branded links in newsletters and ads - Tracking clicks on internal team broadcasts - Creating clean URLs for offline media like QR codes Branded short links: Use shrd.link or bring your own custom domain. Custom slugs: Pick memorable, human-readable URLs for high-visibility campaigns. Real-time analytics: Live clicks, referrers, geolocation, and device breakdowns. Edge-powered redirects: Sub-50ms redirects worldwide so links feel instant. Q: Is the link shortener really free? A: Yes. The free plan includes 50 branded short links and click analytics for the last 7 days, no credit card required. Custom domains start on Pro at $29/mo. Q: Can I use my own domain? A: Yes. Add a custom domain and we provision the hostname automatically through our network for fast, branded redirects. Q: Will my links keep working if I cancel? A: Your active links continue to redirect on the free tier so you do not lose anything you have already shared. ### Real-time link analytics without the bloat. — https://uselinkpilot.com/link-analytics LinkPilot link analytics show every click on every short link the moment it happens. See referrers, devices, countries, and UTM performance side by side, and export anything you need. No cookies on the recipient, no third-party trackers. Use cases: - Measuring campaign performance across channels - Comparing referrer quality for paid versus organic - Identifying which devices and regions convert best - Auditing internal share patterns across teams Live click stream: See clicks land in seconds, not hours. Referrer + UTM breakdown: Group clicks by source, medium, campaign, content, and term. Geo + device insight: Country, city, browser, and OS — no ad-tech tracking required. Privacy-first by default: We hash IPs and never sell visitor data. Q: How is this different from Google Analytics? A: Google Analytics measures sessions on your website. LinkPilot measures clicks on your links — before the visitor reaches a site, often across destinations you do not own. Q: Do recipients know they are being tracked? A: There are no cookies and no client-side scripts on the recipient. We log the redirect event server-side with hashed IPs. Q: Can I export the data? A: Yes — CSV export and a public API are available so you can pipe metrics into your warehouse or dashboards. ### Branded short links your audience trusts. — https://uselinkpilot.com/branded-short-links Branded short links use your own domain instead of a generic shortener, which dramatically improves click-through rate and reduces spam filtering. LinkPilot makes the setup painless and gives every branded link the same analytics, expiry, and audit controls as the rest of your link library. Use cases: - Replacing bit.ly links in marketing campaigns - Shipping branded URLs in newsletters and SMS - Putting trusted short links into print and out-of-home media - Standardizing internal redirects on a company domain Custom domain provisioning: Add a domain, point your DNS, and we handle the rest. Custom slugs: Pick memorable paths like yourbrand.com/launch for hero campaigns. Full analytics: Branded links get the same real-time analytics as default short links. Team controls: Roles, permissions, and audit logs on every branded link. Q: Do branded short links improve click-through rate? A: Yes — branded short links consistently outperform generic shorteners in independent studies, often by double-digit percentages. Q: How long does setup take? A: Most domains are live within a few minutes after you add the DNS record. We surface the exact status in your dashboard. Q: Can I use multiple domains? A: Yes. Use different domains per brand, region, or sub-team — each link can pick the right one at creation time. ## Free tools (full text) ### UTM Builder — https://uselinkpilot.com/tools/utm-builder Free GA4 UTM builder for Google Analytics 4 and Google Ads. Build campaign URLs with utm_source, utm_medium, utm_campaign, utm_term and utm_content. No signup. What is a UTM-tagged URL? UTM parameters are small tags appended to a URL that let analytics platforms attribute traffic to a specific source, medium, and campaign. A consistent UTM strategy is the foundation of accurate marketing attribution — without it, every visit collapses into 'direct' or 'referral'. Use cases: - Paid ad attribution: Tag every ad creative so revenue can be traced back to the exact campaign. - Newsletter tracking: Distinguish click-through from each email send and subject line variant. - Influencer campaigns: Give each partner a unique tagged URL to measure ROI per creator. Q: Are UTM parameters case sensitive? A: Yes. 'Facebook' and 'facebook' will appear as separate sources in most analytics tools. Stick to lowercase. Q: Which UTM parameters are required? A: utm_source, utm_medium, and utm_campaign are required for proper attribution. utm_term and utm_content are optional. Q: Will UTM tags slow down my page? A: No. UTM parameters are query-string metadata and have no effect on page load performance. ### QR Code Generator — https://uselinkpilot.com/tools/qr-code-generator Free QR code generator for any URL. Download high-resolution PNG or SVG QR codes for print, packaging, menus, and signage. No signup, no watermark. Why use QR codes? QR codes bridge the offline-to-online gap by encoding any URL into a square pattern that any modern phone camera can decode. They are essential for print, packaging, signage, and event marketing where typed URLs would create friction. Use cases: - Restaurant menus: Replace laminated cards with scannable codes that link to live menus. - Trade shows: Capture leads instantly by linking attendees to a landing page or contact form. - Product packaging: Drive shoppers from physical packaging to setup guides, warranties, or upsell pages. Q: Do QR codes expire? A: Static QR codes never expire — they encode the URL directly. Dynamic QR codes route through a redirect that you can update at any time. Q: What's the smallest size I can print? A: For reliable scanning, print at minimum 2×2 cm (0.8×0.8 in) with high contrast against the background. Q: Can I customize the colors? A: Yes, but the foreground must remain noticeably darker than the background to preserve scannability. ### Open Graph Preview — https://uselinkpilot.com/tools/open-graph-preview Free Open Graph debugger and social preview checker. Inspect og:title, og:description, og:image and Twitter Card tags to see how your URL renders on social. What are Open Graph tags? Open Graph is a metadata protocol that controls how URLs appear when shared on Facebook, LinkedIn, Slack, iMessage, and most modern platforms. Twitter has its own twitter:card variants that fall back to Open Graph if not specified. Use cases: - Pre-launch QA: Verify share previews before announcing a new product or page. - Debugging cached previews: Spot stale images or descriptions that are still being served. - A/B testing share copy: Compare different titles and images to maximize click-through. Q: Why does my preview not update? A: Most platforms cache Open Graph data for 24+ hours. Use the platform's debugger (Facebook, LinkedIn) to force a refresh. Q: What's the ideal og:image size? A: 1200×630 pixels with a 1.91:1 aspect ratio is the safest choice across platforms. Q: Do I need both og:* and twitter:* tags? A: No. Twitter falls back to Open Graph automatically. Only add twitter:* tags if you want a different preview on Twitter. ### URL Shortener — https://uselinkpilot.com/tools/url-shortener Free URL shortener with custom slugs and click analytics. Turn long links into short, branded URLs you can share anywhere. Free forever plan available. Why shorten URLs? Short URLs are easier to read, type, and share — especially in print, video, podcasts, and character-limited contexts like SMS. A shortener also gives you a layer of indirection: you can update the destination without changing the link itself. Use cases: - Social media bios: Fit more meaning into limited bio space with branded short links. - Print and offline: Make URLs typeable on flyers, business cards, and packaging. - Click tracking: Capture analytics on every link without instrumenting the destination. Q: Are short links permanent? A: Yes — links you create with LinkPilot remain active until you choose to disable or delete them. Q: Can I use my own domain? A: Yes. Connect any domain in your LinkPilot workspace for fully branded short links. Q: Do short links pass SEO value? A: When configured as 301 redirects (the default), short links pass link equity to the destination URL. ### Free Link Shortener — https://uselinkpilot.com/tools/free-link-shortener Free URL shortener, no signup required. Create branded short links, set expiration dates and track clicks — then claim them into a free LinkPilot workspace. What is a free link shortener? A link shortener turns long, unwieldy URLs into compact, shareable links that are easier to read, type, and track. LinkPilot's free tool lets anyone create short links without an account. You get public analytics, optional expiration, and the ability to claim ownership later. Use cases: - Quick sharing: Shorten a URL on the spot for a tweet, DM, or email without creating an account. - Event links: Create time-bounded short links for webinars, promotions, or limited-time offers. - Try before you buy: Test LinkPilot's short links and analytics before signing up for a workspace. Q: Do I need an account? A: No. You can create short links immediately. Signing up lets you claim them into a workspace for private analytics and management. Q: How long do free links last? A: Anonymous links expire after 30 days by default. You can also set a shorter custom expiration. Q: Can I see analytics? A: Yes. Every anonymous link has a public analytics page showing clicks, referrers, and locations — without exposing raw IP addresses. ### Temporary Link — https://uselinkpilot.com/tools/temporary-link Free temporary link generator with automatic expiration. Create short URLs that expire after minutes, hours or days — ideal for time-sensitive sharing. Why use temporary links? Temporary links reduce long-term risk for sensitive or time-bound content. After the expiration window passes, the link stops working and can no longer be accessed. This is ideal for event invites, password reset flows, limited promotions, or any URL you don't want circulating indefinitely. Use cases: - Limited promotions: Share a sale link that automatically expires when the promotion ends. - Event access: Send RSVP or ticket links that are only valid until the event starts. - Private drafts: Share preview URLs for clients that expire after review. Q: Can I change the expiration later? A: Only after claiming the link into a LinkPilot workspace. Anonymous links have a fixed expiration at creation. Q: What happens when a link expires? A: Visitors see a branded LinkPilot expired page. The link can no longer be redirected. Q: Is there a minimum expiration? A: You can set expiration as short as a few minutes. The default for anonymous links is 30 days. ### Link Analytics — https://uselinkpilot.com/tools/link-analytics Free link analytics and click tracking for short URLs. View referrers, locations, device types and click timelines — no account required to create and track. What can link analytics tell you? Link analytics reveal where your traffic comes from, what devices visitors use, and when clicks happen — all without adding tracking scripts to the destination page. This is invaluable for measuring campaign performance, validating channels, and understanding audience behavior across organic and paid distribution. Use cases: - Campaign measurement: Compare click volume across channels to see where your audience is most engaged. - Content validation: Track which headlines, thumbnails, or platforms drive the most interest. - Client reporting: Share public analytics pages with stakeholders without granting dashboard access. Q: Is visitor data private? A: We hash IP addresses daily for rate limiting and never store raw IPs. Analytics show aggregated trends, not individual profiles. Q: Can I export analytics data? A: Export is available after claiming the link into a LinkPilot workspace with a paid plan. Q: How often is data updated? A: Anonymous link analytics update in near real time. Aggregate tables are maintained automatically via database triggers. ### Free Secret Link Generator — https://uselinkpilot.com/tools/free-secret-link-generator Free secret link generator: send a password securely. Encrypted in your browser, burn-after-read, no signup. Passphrase on Pro. A OneTimeSecret alternative. What is a secret link? A secret link encrypts sensitive content in your browser and serves it through a one-time reveal page. The recipient views it once, and then it's gone. This replaces risky habits like emailing passwords, pasting credentials in chat, or sharing API keys through unsecured channels. Use cases: - Password sharing: Send login credentials to teammates or clients without leaving them in email history. - API key delivery: Distribute integration keys to developers with a one-time secure link. - Private notes: Share confidential information that should not be stored permanently on any device. Q: How is the content encrypted? A: In your browser, before anything is sent. The payload is encrypted with AES-GCM-256 using a key generated on your device, and that key is placed in the part of the share link after the # — a URL fragment, which browsers never transmit. We store ciphertext and never receive the key, so we cannot read the secret. Attached files are encrypted the same way, with a key derived from the same link. Browser-side encryption shipped on 29 September 2026; secrets created before that date were stored as plaintext until they expired, and a file's name, size and type remain visible to us. Q: Can the recipient view it more than once? A: By default, secret links are burn-after-read: one view and the content is permanently deleted. You can disable this in advanced settings. Q: Do I need an account? A: No. Secret links can be created anonymously. An account lets you claim them for management and revocation. Passphrase protection is a Pro feature. ### Burn-After-Read Secret — https://uselinkpilot.com/tools/burn-after-read-secret Free burn-after-read secret link tool. Create one-time messages that self-destruct after being opened — the safest way to share sensitive information. How does burn-after-read work? Burn-after-read means the secret is permanently deleted from our servers the moment it is first revealed. Even if the link is shared with multiple people, only the first opener sees the content. This is the digital equivalent of a message written in invisible ink: it exists just long enough to be read, then vanishes completely. Use cases: - One-time credentials: Send a password that can only be used once, eliminating the risk of forwarding or replay. - Private contracts: Share sensitive terms or draft agreements that should not be stored long-term. - Secure handoffs: Transfer access tokens or recovery codes between teams without creating permanent records. Q: What if the recipient doesn't open it? A: Unopened secrets expire after 7 days by default and are permanently deleted. You can set a shorter expiration when creating the link. Q: Can I see if it was opened? A: Yes. The public analytics page shows a view count. After the first view, it shows a burned state and the content is gone. Q: Is there any backup? A: No. Burn-after-read secrets are intentionally non-recoverable. If you need retention, disable burn-after-read in advanced settings. ### Redirect Checker — https://uselinkpilot.com/tools/redirect-checker Free HTTP redirect checker. Trace every hop in a URL's redirect chain — 301, 302, 307, and meta-refresh — with response codes and timings. What is a redirect chain? A redirect chain occurs when a URL forwards to another URL, which forwards again — sometimes through several hops before the final destination is reached. Long chains hurt SEO, slow page loads, and can leak referrer or campaign data along the way. Use cases: - SEO audits: Find chained or looping redirects that waste crawl budget and dilute link equity. - Affiliate link debugging: Confirm that tracking parameters survive every hop to the merchant. - Link rot detection: Catch links that ultimately resolve to 404s or unexpected destinations. Q: What's the difference between 301 and 302? A: 301 is a permanent redirect that passes SEO value; 302 is temporary and tells crawlers not to update their index. Q: Are JavaScript redirects detected? A: Server-side and meta-refresh redirects are. Pure client-side JavaScript redirects require a headless browser to follow. Q: How many redirects is too many? A: Aim for zero. Each extra hop adds latency and risk. More than 3–4 chained redirects is a red flag. ### Link Preview Checker — https://uselinkpilot.com/tools/link-preview-tool Free link preview checker. Paste any URL to see the title, image, and description WhatsApp, Slack, iMessage, Facebook, LinkedIn, Discord, and X will show. How link previews are built Messaging apps and chat platforms scrape a URL's HTML head for Open Graph, Twitter Card, and oEmbed metadata, then assemble a preview card client-side. If those tags are missing, platforms fall back to the and the first usable image they can find — often with poor results. Every platform reads the same core tags — og:title, og:description, og:image, and og:url — but each renders them differently: Slack and Discord show a full card with description, iMessage shows title and domain over the image, and WhatsApp usually crops the image to a small square thumbnail. Check the platform-specific pages below when a preview looks right in one app and wrong in another. Use cases: - Content QA: Verify previews look good before sharing in Slack, iMessage, or WhatsApp. - Editorial workflows: Confirm article metadata is correct before publishing or syndicating. - Outreach: Make sure cold emails and DMs render an attractive card every time. Q: What is a link preview? A: A link preview is the card — title, description, and image — that a messaging app or social network shows in place of a bare URL. It is built from metadata in the page's HTML head: Open Graph tags (og:title, og:description, og:image) and, on some platforms, Twitter Card tags. If those tags are missing, the platform falls back to the <title> tag and whatever image it can find. Q: Why is my link preview not showing? A: The most common causes are missing Open Graph tags, an og:image that is not publicly reachable over HTTPS, a page that blocks crawlers (robots.txt, bot protection, or a 401/403 response), or metadata that is only injected by client-side JavaScript. Platforms also cache previews, so a fix may not appear until the cached copy is refreshed. Q: What image size do link previews use? A: 1200×630 pixels (a 1.91:1 ratio) is the widely recommended og:image size and renders well on Facebook, LinkedIn, Slack, Discord, and iMessage. Keep the file under about 5 MB, serve it over HTTPS, and keep important content away from the edges — some apps, including WhatsApp, crop the image to a small square thumbnail. Q: How do I fix a wrong link preview? A: Update the Open Graph tags in the page's HTML, confirm the new values with this checker, then clear the platform's cache: Facebook's Sharing Debugger ('Scrape Again'), LinkedIn's Post Inspector, or X's Card Validator. Slack, Discord, WhatsApp, and iMessage have no public debugger — append a throwaway query parameter (for example ?v=2) so the URL is fetched as a new link. Q: Do single-page apps work? A: Only if they server-render metadata or pre-render for crawlers. Client-only SPAs typically produce blank previews because social scrapers do not execute JavaScript. ### Bio Link Generator — https://uselinkpilot.com/tools/bio-link-generator Free Linktree alternative for Instagram, TikTok, and X bios. Host every link behind one short URL with built-in click analytics — no signup required to try. Why creators use bio links Most social platforms allow only one outbound link in a profile. A bio link page solves this by hosting every URL you care about behind a single short link. It also gives you analytics on which links your audience actually clicks. Use cases: - Creator profiles: Link to merch, latest video, newsletter, and sponsorship inquiries from one place. - Podcast hubs: Send listeners to every podcast platform without picking favorites. - Event landing pages: Aggregate ticket links, schedules, and venue info for an event. Q: Do I need a custom domain? A: No — you can use a default short domain. Custom domains are available on paid plans for branded URLs. Q: Can I edit my bio link page later? A: Yes. Update links, ordering, and styling anytime; changes are live instantly. Q: Is it mobile optimized? A: Yes. Bio link pages are designed mobile-first since the vast majority of traffic comes from social apps. ### AI CTA Generator — https://uselinkpilot.com/tools/cta-generator Free AI call-to-action generator. Get six conversion-tested CTA ideas in your chosen tone — professional, creator, ecommerce, urgent, or minimalist. No signup. What makes a CTA convert? Strong CTAs are short, specific, and action-led — they tell the visitor exactly what happens next and why it benefits them. The best CTAs reduce perceived risk ('Start free', 'No credit card') while creating gentle urgency ('today', 'now'). Tone matters: a creator audience reads differently than an enterprise buyer. Use cases: - Landing page hero: Generate the primary above-the-fold button copy that drives signups. - Email campaigns: Write subject-line-aligned button text for newsletters and lifecycle emails. - Ad creative: Test multiple CTA variants on paid ads to lift click-through rate. Q: How long should a CTA be? A: Two to four words is the sweet spot. Long enough to be specific, short enough to scan instantly. Q: Should I use 'click here'? A: No. 'Click here' tells the user nothing about the outcome. Use action verbs that describe the result. Q: How many CTA variants should I test? A: Start with 3–4 distinct variants per placement, then iterate on the winner. ### CTR Optimization Suggestions — https://uselinkpilot.com/tools/ctr-optimizer Free AI CTR optimizer for links and CTAs. Paste any URL for suggestions on stronger calls-to-action, branded slugs and cleaner URLs that drive more clicks. Why click-through rate matters Click-through rate (CTR) is the single biggest lever for paid and organic distribution: a 1% lift in CTR compounds across every impression you ever buy or earn. Three factors drive CTR on a shared link: the framing copy around it, the readability of the URL itself, and the clarity of the destination promise. Use cases: - Pre-launch audit: Polish CTAs and slugs before pushing a campaign live. - Underperforming links: Diagnose why an existing link isn't earning clicks and get fixes. - Newsletter optimization: Tighten the copy that wraps each link in your sends. Q: What's a 'good' CTR? A: It depends on context. Email CTRs above 2.5% are strong; social link CTRs above 1.5% are competitive; ad CTRs vary wildly by network. Q: Will changing the URL break analytics? A: If you're using LinkPilot short links, you can update the destination without changing the short URL — analytics stay intact. Q: Are branded slugs really better? A: Yes. Readable slugs like /spring-sale outperform random slugs like /a8f3k in click-through tests, especially for email and print. ### Link Trust Score — https://uselinkpilot.com/tools/link-trust-score Free URL safety and trust checker. Paste any link for an instant 0–100 trust score with a breakdown of readability, security and phishing patterns. What signals trust in a URL? Users decide whether to click a link in milliseconds based on its surface signals: protocol (HTTPS), domain familiarity, length, and the absence of suspicious patterns like raw IP addresses, punycode tricks, or excessive subdomains. A trustworthy short link looks intentional: a recognizable domain, a clean slug, and no random query-string noise. Use cases: - Pre-share QA: Check that the link you're about to send isn't going to look phishy. - Vendor link review: Quickly evaluate links you receive from third parties. - Brand audits: Assess your own short links from your audience's perspective. Q: How is the score calculated? A: We score across protocol, domain length and structure, slug readability, query-string noise, and known suspicious patterns. Each contributes to a final 0–100 score. Q: Does a high score guarantee a link is safe? A: No. Trust score measures readability and surface-level signals, not malware or phishing. Always verify the destination before clicking unfamiliar links. Q: Why does my legitimate URL score low? A: Long tracking parameters, deep paths, or unusual TLDs can lower the score. Consider shortening the link with a branded short domain. ### Smart Link Suggestions — https://uselinkpilot.com/tools/smart-link-suggestions Free AI link hygiene tool. Get instant recommendations for cleaner slug naming, UTM parameter cleanup, and branded short-domain ideas for any URL. Why link hygiene matters Sloppy links — long random slugs, duplicated UTMs, inconsistent naming — quietly erode brand trust and corrupt analytics. The fix is a small set of conventions applied consistently. Branded short domains, predictable slugs, and clean UTM parameters compound into measurably better attribution and click-through over time. Use cases: - Naming conventions: Adopt a slug pattern your whole team can follow without thinking. - UTM cleanup: Spot redundant or inconsistent UTM parameters before they pollute your analytics. - Branded domain ideas: Brainstorm short-domain options that match your brand voice. Q: Why use a branded short domain? A: Branded domains (e.g. acme.link) outperform generic shorteners in click-through and trust tests, and they reinforce brand recall. Q: What's wrong with messy UTMs? A: Inconsistent casing, duplicated parameters, and missing required fields all fragment your analytics. Cleanup pays back immediately in clearer reporting. Q: Should every link have UTMs? A: Only links where attribution matters — paid ads, newsletters, partner placements. Don't UTM internal navigation links. ## Comparison pages (full text) ### LinkPilot vs Bitly — https://uselinkpilot.com/compare/linkpilot-vs-bitly A modern alternative to Bitly with built-in analytics, smart rules, secret links, and a generous free tier. Bitly invented modern URL shortening and is still the brand most people recognise. It does the core job — turn long URLs into short, trackable ones — reliably, with a clean dashboard, QR codes, and a healthy API ecosystem. What it doesn't do well is bundle. Mobile/OS-aware deep links, geo and device targeting, audit logs, public API access, secret sharing, and AI assistance are scattered across paid tiers — and several only appear at enterprise pricing with a sales call attached. LinkPilot bundles the smart-link, attribution, and conversion-intelligence features Bitly charges premium for into a workspace built for product, growth, and agency teams — plus a separate secret-sharing workflow so passwords and tokens never end up in campaign analytics. LinkPilot is a workspace product, not just a shortener. Branded short links, mobile/OS-aware deep links, geo and device targeting, Rule Studio (with simulator and shadow mode), AI CTA suggestions, trust scoring, secret links, agency white-label, and a public API ship together in the same product — without an enterprise call. Why teams switch: - All the smart-redirect features (mobile, geo, device) without an enterprise upsell. - Conversion-focused — AI CTAs, trust scoring, and rule shadow mode beat plain shortening. - Modern UX built for teams: roles, audit logs, agency workspaces, and brand kits. - Public API + webhooks on every paid tier — automate without enterprise gating. Verdict: Bitly is the safe, recognisable choice; LinkPilot is the better-value, more capable choice. If you care about bundled features, secret sharing, and self-serve access to the entire platform, switch. If your stakeholders need to see the letters "bit.ly" on a link, stay. Q: Can I import my Bitly links to LinkPilot? A: Yes — use the CSV import flow under Links → Import. Map your existing slugs and destination URLs in one pass. Q: Will my existing short links keep working if I switch? A: Bitly links live on bit.ly. To migrate, point a custom domain at LinkPilot and recreate the slugs you care about, or 301 the old domain at the new short links. Q: How does pricing compare? A: LinkPilot bundles features (custom rules, AI, secret links, audit logs) that Bitly gates behind enterprise pricing. For most teams, switching is a meaningful unit-cost reduction. Q: Does LinkPilot have an API? A: Yes — a full REST API with scoped keys (lp_live_*) is available on paid plans, plus outgoing webhooks for click and link events. Q: Is LinkPilot reliable at scale? A: Redirects resolve through a Cloudflare edge network with regional failover, per-tenant rate limiting, and aggregate analytics maintained via database triggers. Q: What about secret sharing? A: Secret links are a first-class feature with passphrases hashed client-side, atomic burn-after-read, file attachments behind signed URLs, and a per-secret audit timeline. ### LinkPilot vs Dub — https://uselinkpilot.com/compare/linkpilot-vs-dub A team-first alternative to Dub with deeper attribution, secret links, and agency workspaces. Dub is a beautiful, modern shortener with strong developer ergonomics — clean API, polished UI, and an open-source core. It's a great pick for engineering-led teams that want a tidy primitive to build on. LinkPilot is built for cross-functional teams — marketing, product, sales, and agencies — that need conversion intelligence on top of the shortening primitive. AI CTAs, trust scoring, secret links, and a Rule Studio with simulator and shadow mode ship in the same workspace. Both products are excellent at the core job. The decision is mostly about scope: do you want a focused link primitive (Dub), or a workspace that also covers secrets, redirect logic, and agency operations (LinkPilot)? LinkPilot is a workspace product, not just a shortener. Branded short links, mobile/OS-aware deep links, geo and device targeting, Rule Studio (with simulator and shadow mode), AI CTA suggestions, trust scoring, secret links, agency white-label, and a public API ship together in the same product — without an enterprise call. Why teams switch: - Rule Studio with conflict detection, simulator, and shadow mode — ship redirect logic with confidence. - Secret links cover encrypted payloads, IP-binding, and burn-after-read use cases plain shorteners can't. - Agency-grade workspaces with brand kits, shared reports, and per-client white-label. - Trust scoring + interstitials help users click links from your brand with confidence. Verdict: Dub is a great primitive; LinkPilot is a more complete platform. If you want a focused, open-source shortener, Dub is a fine pick. If you want a workspace that also handles secrets, redirect logic, and agency operations, LinkPilot is the better fit. Q: Is LinkPilot open-source like Dub? A: LinkPilot is a managed product. We focus on a hosted, multi-tenant experience with RLS-based isolation, audit logging, and rate limiting baked in. Q: Can I migrate from Dub? A: Yes — export your links to CSV from Dub, then use LinkPilot's CSV import to recreate them. Custom domains can be re-pointed via DNS. Q: Which has a better API? A: Both ship clean REST APIs. LinkPilot adds outgoing webhooks for click and link events on every paid tier, plus tenant-scoped audit log access. Q: What about pricing? A: LinkPilot's pricing is competitive at the team and agency tiers and includes more attribution features (Rule Studio, secret links, trust score) per dollar. Q: Does LinkPilot offer rule simulation? A: Yes — Rule Studio includes a simulator and shadow mode, so you can validate logic against real traffic before publishing. Q: Are secrets really separate from analytics? A: Yes — secret contents are stored and served on a separate workflow. They never enter campaign or click analytics. ### LinkPilot vs TinyURL — https://uselinkpilot.com/compare/linkpilot-vs-tinyurl An analytics-first alternative to TinyURL — built for teams that need more than a shortener. TinyURL has been around since 2002 and remains one of the simplest URL shorteners on the internet. Paste a URL, get a short URL, done. No account required. For one-off shortening with no analytics or branding, it's hard to beat. But the moment you need to know which links work — let alone improve them, secure them, or share them across a team — TinyURL's free tier runs out of room and its paid tiers don't catch up to a modern workspace product. LinkPilot is a workspace: branded domains, real-time click analytics on every link (including anonymous ones), team roles, AI suggestions, secret links, trust scoring, and a public API. The free tier gives you analytics, password protection, and expiration on every short URL — controls TinyURL puts behind paid plans. LinkPilot is a workspace product, not just a shortener. Branded short links, mobile/OS-aware deep links, geo and device targeting, Rule Studio (with simulator and shadow mode), AI CTA suggestions, trust scoring, secret links, agency white-label, and a public API ship together in the same product — without an enterprise call. Why teams switch: - Real analytics — country, device, browser, and per-link conversion charts on every link. - Branded short links on your own domain build trust and CTR. - Team-ready: roles, invites, audit logs, and per-workspace billing. - Conversion intelligence (AI, trust, rules) — not just shortening. Verdict: TinyURL is fine for one-off personal use. For anything else — a team, a campaign you'll measure, or a link you might want to edit later — LinkPilot is a strictly better product, and the free tier already covers most of the gaps. Q: Is LinkPilot free like TinyURL? A: Yes — LinkPilot has a free tier that includes analytics, custom rules, and secret links. Paid tiers add team seats, branded domains, and API access. Q: Can I migrate TinyURL links? A: TinyURL doesn't expose a bulk export, but you can recreate the slugs that matter using LinkPilot's CSV import or API. Q: Do I need a developer to use LinkPilot? A: No. The dashboard covers everything: links, rules, analytics, and team management. The API is there when you need it. Q: What about reliability? A: LinkPilot resolves redirects through a Cloudflare edge network with regional failover and per-tenant rate limiting. Q: Will my old TinyURL links keep working? A: Existing tinyurl.com links remain on TinyURL's network. For new campaigns, create them on LinkPilot — analytics start from day one. ### LinkPilot vs Rebrandly — https://uselinkpilot.com/compare/linkpilot-vs-rebrandly A bundled alternative to Rebrandly — branded links plus AI, secret links, and Rule Studio without per-link metering. Rebrandly pioneered branded short links and remains a solid choice if all you need is custom-domain shortening at scale. Its dashboard is well-built, its API is reliable, and its custom-domain catalogue is one of the deepest in the category. The pricing model is where it starts to chafe. Rebrandly meters branded links, tracked clicks, and custom domains as separate line items per plan. Active teams routinely upgrade not because they need more features, but because they've used up their metered quota. LinkPilot bundles branded domains, smart redirects, AI suggestions, secret links, Rule Studio, and trust scoring into flat workspace tiers — so you stop counting links and start shipping campaigns. LinkPilot is a workspace product, not just a shortener. Branded short links, mobile/OS-aware deep links, geo and device targeting, Rule Studio (with simulator and shadow mode), AI CTA suggestions, trust scoring, secret links, agency white-label, and a public API ship together in the same product — without an enterprise call. Why teams switch: - Flat workspace pricing — no per-branded-link or per-tracked-click meter to manage. - Conversion intelligence built in: AI CTAs, trust score, and Rule Studio ship in every paid tier. - Secret links cover encrypted, expiring, and burn-after-read use cases Rebrandly doesn't handle. - Agency console with brand kits and white-label, not a custom-quoted enterprise add-on. Verdict: Rebrandly is a strong domain-centric shortener; LinkPilot is the more complete and more predictably-priced workspace. If branded shortening is all you need and you're under your quotas, stay. If your bill keeps growing because of metering or you want more in the same product, switch. Q: Can I import my Rebrandly links? A: Yes — export your Rebrandly links to CSV and use LinkPilot's CSV import under Links → Import to recreate them with the same slugs. Q: Will my custom domain keep working? A: Yes. Re-point your branded domain's DNS at LinkPilot following the Domains setup guide and your links keep resolving with no downtime if you cut over carefully. Q: How does pricing actually compare? A: Rebrandly meters branded links, tracked clicks, and custom domains per plan. LinkPilot bundles them into flat workspace tiers, which is typically a meaningful unit-cost reduction for active teams. Q: Does LinkPilot support team roles like Rebrandly? A: Yes — five roles (owner, admin, member, billing, viewer) with permission gates, plus tenant-scoped audit logs on every paid tier. Q: What about secret sharing? A: Secret links are a first-class feature with passphrases hashed client-side, atomic burn-after-read, and file attachments. Rebrandly doesn't offer this. ### LinkPilot vs Short.io — https://uselinkpilot.com/compare/linkpilot-vs-short-io An agency-ready alternative to Short.io with white-label workspaces, trust scoring, and secret links. Short.io is a popular domain-centric shortener — bring your own domain, get clean analytics, ship branded links fast. It works well for solo marketers and small teams who already know how they want to structure their links. Where it slows down is multi-client work, redirect logic that needs testing before going live, and any workflow that involves sharing secrets. Those gaps push teams either to bolt on extra tools or upgrade into a more expensive tier than they wanted. LinkPilot is built for teams and agencies that need more than shortening: per-client workspaces, white-label branding, AI copy, trust scoring, secret links, and a Rule Studio for redirect logic you can test before publishing. LinkPilot is a workspace product, not just a shortener. Branded short links, mobile/OS-aware deep links, geo and device targeting, Rule Studio (with simulator and shadow mode), AI CTA suggestions, trust scoring, secret links, agency white-label, and a public API ship together in the same product — without an enterprise call. Why teams switch: - Agency console with per-client workspaces, brand kits, and white-label out of the box. - Rule Studio lets you simulate and shadow-test redirect rules before they hit production traffic. - Secret links unlock encrypted, expiring, and burn-after-read sharing — beyond what a shortener handles. - Trust scoring and safe-redirect interstitials add a layer Short.io doesn't offer. Verdict: Short.io is a great single-team shortener; LinkPilot is the better choice when you outgrow a single team — agencies, multi-client work, or workflows that involve redirect logic and secrets in the same product. Q: Can I migrate my Short.io links? A: Yes — export to CSV from Short.io and import via LinkPilot's CSV importer. Re-point the custom domain via DNS to keep slugs resolving. Q: Does LinkPilot offer multiple domains like Short.io? A: Yes. Add as many custom domains as your plan supports, each with its own slug namespace, branding, and rules. Q: How does white-label work in LinkPilot? A: Agency tiers let you brand the dashboard, email, and shared report surfaces per client workspace — logo, palette, and custom domain included. Q: What about analytics? A: Real-time per-link analytics, geo and device breakdowns, public shareable reports, and exportable data on every paid tier. Q: Do you support team roles? A: Yes — 5 roles built in (owner, admin, member, billing, viewer) with permission gates and tenant-scoped audit logs. ### LinkPilot vs T.ly — https://uselinkpilot.com/compare/linkpilot-vs-tly A team-grade alternative to T.ly with deeper RBAC, audit logs, AI, and conversion-intelligence features. T.ly is a popular shortener — friendly free tier, simple UI, and well-known in the lifetime-deal world. It's a fine pick if you need a personal or small-team shortener with branded links and basic analytics. Where it stops short is real team controls (RBAC beyond a basic team space), audit logs, conversion intelligence (AI, trust score, rule simulation), and a separate secret-sharing workflow. LinkPilot is a workspace product: five-role RBAC, tenant-scoped audit logs, AI suggestions, secret links, Rule Studio, and an agency console for teams that need redirect logic and conversion intelligence, not just short URLs. LinkPilot is a workspace product, not just a shortener. Branded short links, mobile/OS-aware deep links, geo and device targeting, Rule Studio (with simulator and shadow mode), AI CTA suggestions, trust scoring, secret links, agency white-label, and a public API ship together in the same product — without an enterprise call. Why teams switch: - Real team controls — five roles, audit logs, and per-workspace billing rather than a flat team space. - Rule Studio plus shadow mode let you ship redirect logic without breaking active campaigns. - Secret links and trust scoring cover use cases a pure shortener can't. - Agency console with white-label workspaces — bring on clients without standing up another tenant. Verdict: T.ly is good value for a personal or small-team shortener; LinkPilot is the better pick once your team needs real RBAC, audit logs, or conversion intelligence. Q: Can I import my T.ly links? A: Yes — export your T.ly links to CSV and use LinkPilot's CSV import to recreate them with the same slugs and destinations. Q: Does LinkPilot have a free tier like T.ly? A: Yes. The free plan includes analytics, custom rules, and secret links. Paid tiers add team seats, branded domains, AI, and API access. Q: What about the API? A: LinkPilot ships a scoped REST API (lp_live_* keys) plus outgoing webhooks for click and link events on every paid tier. Q: Is LinkPilot reliable for high-traffic links? A: Yes — redirects resolve through a Cloudflare edge network with regional failover and per-tenant rate limiting. Q: Do you offer audit logs? A: Yes — tenant-scoped audit logs on every paid tier, with hashed IPs and event-level detail. ### LinkPilot vs BL.INK — https://uselinkpilot.com/compare/linkpilot-vs-blink A modern alternative to BL.INK with bundled AI, secret links, and trust scoring — no enterprise sales cycle required. BL.INK is an enterprise-focused link management platform with strong governance, SSO, and SLAs. It's a fit for large enterprises that buy through procurement and need contractual commitments before they touch a tool. If you're not buying through procurement, BL.INK is hard to evaluate — there's no self-serve free tier, no public pricing for most features, and onboarding involves a sales call. LinkPilot delivers the same governance primitives — RLS-based multi-tenancy, audit logs, RBAC, rate limiting — with a modern self-serve experience, a generous free tier, and bundled AI, secret links, and trust scoring you don't have to negotiate for. LinkPilot is a workspace product, not just a shortener. Branded short links, mobile/OS-aware deep links, geo and device targeting, Rule Studio (with simulator and shadow mode), AI CTA suggestions, trust scoring, secret links, agency white-label, and a public API ship together in the same product — without an enterprise call. Why teams switch: - Self-serve from free to paid — no sales call required to ship branded short links. - Bundled AI, secret links, trust scoring, and Rule Studio that BL.INK doesn't ship at all. - Modern dashboard built for marketers and product teams, not just procurement-approved governance. - Transparent pricing with flat workspace tiers instead of custom enterprise quotes. Verdict: BL.INK wins on enterprise sales motion; LinkPilot wins on bundled features, self-serve access, and transparent pricing. Most teams that aren't in enterprise procurement will find LinkPilot strictly better. Q: Is LinkPilot enterprise-ready? A: Yes — RLS-based multi-tenant isolation, 5-role RBAC, tenant-scoped audit logs, rate limiting, and SSO-ready architecture. The difference is you can start free and upgrade without procurement. Q: Can I migrate from BL.INK? A: Yes — export your links to CSV and import via LinkPilot. Custom domains can be re-pointed via DNS during a cutover window. Q: Do you offer SSO? A: SSO is available on higher tiers. Reach out for SAML configuration; the underlying auth supports it. Q: What about uptime and SLAs? A: Redirect traffic resolves through a Cloudflare edge network with regional failover. Paid tiers include availability commitments and incident response. Q: Do you sign a DPA? A: Yes — a Data Processing Agreement is available on paid tiers. ### LinkPilot vs OneTimeSecret — https://uselinkpilot.com/compare/linkpilot-vs-onetimesecret A team-grade alternative to OneTimeSecret with audit logs, file attachments, RBAC, and bundled short links. OneTimeSecret is a well-known open-source one-time secret tool. It does one thing — burn-after-read text secrets — and it does it cleanly. For ad-hoc personal sharing or a quick self-hosted instance, it's hard to beat. Where it runs out of room is anything team-shaped. There's no workspace, no audit log per secret beyond what you store yourself, no RBAC, no file attachments on the hosted tier, and no way to revoke a secret from a dashboard. LinkPilot offers the same core burn-after-read primitive plus team workspaces, audit timelines (created, viewed, burned, revoked), file attachments behind signed URLs, branded short links, and an API — all in one tenant-isolated workspace. LinkPilot is different from a pure secret-sharing tool. It pairs a first-class burn-after-read primitive (passphrase-protected, expiring, file attachments, atomic row-locked reveal) with a full short-link platform — branded domains, real-time analytics, audit logs, RBAC, and an API — all in the same tenant-isolated workspace. Secret contents are kept on a separate workflow from analytics, so passwords and tokens never enter campaign data. Why teams switch: - Audit timeline per secret — created, viewed, burned, revoked — without bolt-on logging. - Team workspaces with RBAC, so sensitive shares aren't tied to a single user's session. - File attachments behind the same burn / passphrase / expiry controls. - Branded short links and analytics in the same workspace, on a strictly separate workflow. Verdict: OneTimeSecret is a great single-purpose primitive; LinkPilot is the better pick for teams that need an audit trail, file attachments, RBAC, or any of the surrounding link tooling. Q: Is LinkPilot a drop-in replacement for OneTimeSecret? A: For the burn-after-read workflow, yes — and you also get team controls, audit logs, and the rest of a link platform. If you specifically want a self-hosted single-purpose tool, OneTimeSecret remains a solid choice. Q: Can I self-host LinkPilot? A: LinkPilot is a hosted SaaS. If self-hosting is a hard requirement, OneTimeSecret's open-source edition is the better fit. Q: Are secrets used for analytics or profiling? A: No. Secret contents are handled separately from short-link analytics and are never used for campaign analytics, profiling, or retargeting. Q: What expiry options are available? A: 1 hour, 24 hours or 7 days on any plan, with a custom date and time on Pro, plus burn-after-read so the first view ends the secret regardless of the expiry window. Q: Can I attach files? A: Yes — file attachments sit behind the same burn / passphrase / expiry controls as text secrets, served via short-lived signed URLs. ### LinkPilot vs Privnote — https://uselinkpilot.com/compare/linkpilot-vs-privnote A team-grade alternative to Privnote with audit logs, revocation, file attachments, and bundled short links. Privnote is a quick, anonymous way to send a self-destructing note. No signup, no UI to learn, paste a message and share the link. For one-off personal use it's perfect. Where it stops is everything around the note. There's no way to revoke an unread note from a dashboard, no record of who created or viewed it, no team workspace, and no file attachments beyond the basics on a paid tier. LinkPilot covers the same self-destructing-note use case for individuals and adds the team controls — roles, audit logs, revocation, branded links, analytics — that businesses tend to need. LinkPilot is different from a pure secret-sharing tool. It pairs a first-class burn-after-read primitive (passphrase-protected, expiring, file attachments, atomic row-locked reveal) with a full short-link platform — branded domains, real-time analytics, audit logs, RBAC, and an API — all in the same tenant-isolated workspace. Secret contents are kept on a separate workflow from analytics, so passwords and tokens never enter campaign data. Why teams switch: - Audit timeline per secret means you can prove a sensitive value was viewed (or wasn't). - Revocation from a dashboard — burn an unread secret without waiting for it to expire. - File attachments behind the same controls as text secrets. - Branded short links and analytics in the same workspace, on a separate workflow. Verdict: Privnote is fine for purely personal anonymous notes. For anything you'd want to prove was viewed, revoke, or share as a team, LinkPilot is the safer choice. Q: Should I switch from Privnote to LinkPilot? A: If you're sharing on behalf of a team and want auditability or revocation, yes. For purely anonymous personal notes, Privnote is still fine. Q: Does LinkPilot read my secrets? A: No. Secret contents are kept separate from short-link analytics and are never used for profiling, retargeting, or marketing analytics. Q: Can I add a passphrase like Privnote does? A: Yes — passphrases are hashed client-side before the secret leaves your browser. Q: What expiry options are available? A: 1 hour, 24 hours or 7 days on any plan, with a custom date and time on Pro, plus burn-after-read so the first view ends the secret regardless of expiry. Q: Can I revoke a secret? A: Yes — unread secrets can be revoked from the dashboard at any time before view. ### LinkPilot vs Password Pusher — https://uselinkpilot.com/compare/linkpilot-vs-password-pusher A workspace alternative to Password Pusher with audit logs, file attachments, branded short links, and a public API. Password Pusher is a well-loved open-source tool for sharing passwords via expiring URLs. It supports view-count caps, expiry windows, deletable links, and self-hosting, and it's been a standard in IT and engineering teams for years. Where it stops short is everything around the password itself. There's a per-link deletable URL, but no per-tenant audit trail; there's a hosted version, but no real team workspace with RBAC; there's a file-pushing module, but no unified workspace that also covers branded short links and analytics. LinkPilot covers the same expiring-secret use case — passphrase, expiry, view-count, deletable URL — and pairs it with team workspaces, tenant-scoped audit logs, file attachments behind signed URLs, branded short links, and a public API. LinkPilot is different from a pure secret-sharing tool. It pairs a first-class burn-after-read primitive (passphrase-protected, expiring, file attachments, atomic row-locked reveal) with a full short-link platform — branded domains, real-time analytics, audit logs, RBAC, and an API — all in the same tenant-isolated workspace. Secret contents are kept on a separate workflow from analytics, so passwords and tokens never enter campaign data. Why teams switch: - Per-tenant audit logs and per-secret event timelines come standard. - RBAC, file attachments, and branded short links in one product. - Hashed-IP recipient privacy without any extra configuration. - Hosted SaaS — no instance to run, patch, or back up. Verdict: Password Pusher is a great open-source tool if you can self-host; LinkPilot is the better pick if you want a hosted workspace with audit trails, RBAC, and branded short links alongside the secret-sharing primitive. Q: Can I self-host LinkPilot like Password Pusher? A: No — LinkPilot is hosted SaaS. If self-hosting is a hard requirement, Password Pusher is the better fit. Q: Does LinkPilot support view-count caps? A: LinkPilot's primary primitive is burn-after-read (N=1) with optional passphrase, expiry, and IP-binding. For specifically-N-views semantics, Password Pusher is the closer match. Q: Can I attach files? A: Yes — file attachments sit behind the same burn / passphrase / expiry controls as text secrets and are served via short-lived signed URLs. Q: Are secrets isolated per tenant? A: Yes — every secret is stored in a multi-tenant database with row-level security policies that enforce tenant boundaries on every query. Q: Do you offer a public API? A: Yes — scoped REST API (lp_live_* keys) plus webhooks for secret and link events on every paid tier. Q: How does pricing compare? A: Password Pusher is free / sponsorship-funded when self-hosted. LinkPilot is a paid SaaS with a generous free tier; you trade hosting effort for a workspace product. ### LinkPilot vs PrivateBin — https://uselinkpilot.com/compare/linkpilot-vs-privatebin A hosted, team-grade alternative to PrivateBin — audit logs, revocation, and short links without running your own instance. PrivateBin is an open-source, client-side-encrypted pastebin. The server stores only ciphertext — the decryption key travels in the URL fragment and never reaches the server. If zero-knowledge end-to-end encryption is a hard requirement and you can self-host, it is an excellent tool. What PrivateBin doesn't try to be is a team product. There is no dashboard of active shares, no revocation from a console, no per-secret audit timeline, no roles, and running it means operating and patching your own instance. LinkPilot uses the same encryption model for text secrets — AES-GCM-256 in the browser, key in the URL fragment, ciphertext on the server — and wraps it in a hosted workspace: burn-after-read, per-secret audit timelines, revocation, file attachments, and branded short links with analytics. The honest differences that remain are hosting and auditability, not encryption: PrivateBin is open source and self-hosted so you can verify the client yourself, LinkPilot is closed-source SaaS. LinkPilot is different from a pure secret-sharing tool. It pairs a first-class burn-after-read primitive (passphrase-protected, expiring, file attachments, atomic row-locked reveal) with a full short-link platform — branded domains, real-time analytics, audit logs, RBAC, and an API — all in the same tenant-isolated workspace. Secret contents are kept on a separate workflow from analytics, so passwords and tokens never enter campaign data. Why teams switch: - No instance to operate — hosted, patched, and backed by rate limiting and RLS isolation. - Per-secret audit timeline and dashboard revocation that a static pastebin can't provide. - File attachments, team roles, and notification on view in the same product. - Branded short links and privacy-first analytics on a strictly separate workflow. Verdict: The encryption row is now a tie for text secrets — both encrypt in the browser and neither server sees a key. PrivateBin still wins if you need to read the client source yourself, self-host, or encrypt attachments end to end. LinkPilot wins on everything around the secret: hosting, auditability, revocation, teams, and the surrounding link platform. Q: Does LinkPilot offer end-to-end encryption like PrivateBin? A: Yes, for text secrets, and by the same method: AES-GCM-256 in your browser with the key in the URL fragment, so the server only ever holds ciphertext. Two differences we will not paper over — PrivateBin is open source so you can audit its client, and PrivateBin's client is auditable in a way ours is not. Our security architecture page spells out the exact model. Q: Why pick LinkPilot if PrivateBin is open source and free? A: You trade self-hosting effort for a hosted workspace: team roles, audit timelines, revocation, file attachments, notification on view, and branded short links with analytics — none of which PrivateBin provides. Q: Can I revoke a secret after sending it? A: Yes — unread secrets can be revoked from the dashboard at any time, and the revocation is recorded in the audit timeline. Q: Are secrets used for analytics? A: Never. Secret contents are kept on a separate workflow from short-link analytics and are excluded from profiling and AI features. Q: Can I attach files? A: Yes. File attachments sit behind the same burn, passphrase and expiry controls as text secrets and are served via short-lived signed URLs. They are encrypted in your browser like the text payload, with a key derived from the same link. Browser-side encryption shipped on 29 September 2026; secrets and files created before that date were stored as plaintext until they expired, and a file's name, size and type remain visible to us. ## Glossary (full text) — https://uselinkpilot.com/glossary ### Core Concepts & URL Anatomy Short link / Short URL A condensed version of a longer web address, typically generated by a URL shortening service. Short links are easier to share, remember, type, and display in space-constrained environments such as social media posts, printed materials, SMS messages, signage, or QR codes. Example: `https://sho.rt/abc123` in place of a long URL containing paths, query strings, tracking parameters, or product identifiers. Long URL / Destination URL The full web address that a short link redirects to. Also called the target URL or destination, it is where a user ultimately lands after clicking or scanning the short link. Long URLs often contain tracking parameters, product IDs, filters, session-independent state, or other structured data that can make them difficult to share directly. Original URL The URL as entered by the user when creating a short link. In many platforms this is synonymous with long URL, destination URL, or target URL. In some workflows, the original URL may later differ from the current destination if the short link supports destination editing. Target URL The active URL to which a short link currently redirects. The target URL may be the same as the original URL or may be changed later if the platform supports editable destinations. Slug The unique character sequence appended to a short link's domain that identifies a specific link record. In `https://sho.rt/abc123`, the slug is `abc123`. Slugs can be generated automatically, usually as random or sequential alphanumeric strings, or manually defined by the user as a custom alias. Custom alias A user-defined slug chosen to make a short link more readable, memorable, or campaign-specific. Instead of a random string like `x7k9p`, a custom alias might be `summer-sale`, `event-rsvp`, or `product-launch`. Custom aliases are usually subject to availability, length rules, reserved-word restrictions, and plan limits. Custom back-half An industry term for the user-defined portion of a short link that comes after the domain. In `https://brand.co/summer-sale`, the custom back-half is `summer-sale`. This term is commonly used by link management platforms and is effectively equivalent to a custom alias. Reserved alias A slug or custom alias that cannot be used because it is already taken, protected by the platform, reserved for system routes, restricted for brand or abuse reasons, or considered offensive or misleading. Examples may include `admin`, `login`, `support`, or aliases that impersonate major brands. Vanity URL A branded, human-readable URL designed to be memorable and trustworthy. In link management, a vanity URL often combines a branded domain with a custom alias, such as `https://brand.co/summer-sale`. More broadly, the term can also refer to any memorable marketing URL, even when it is not produced by a link shortening platform. Branded link A short link that uses a brand-owned or brand-aligned domain instead of a generic shared shortener domain. Branded links improve recognition, trust, click confidence, and consistency across campaigns. Example: `https://go.example.com/demo` instead of `https://bit.ly/abc123`. URL shortener A service, application, or tool that takes a long web address and produces a shorter one that redirects to the same destination. URL shorteners keep a record of which short link maps to which destination and handle the redirect each time someone clicks. You may also see this described informally as "URL compression," though nothing is technically compressed — the short link simply acts as an alias that points to the original address. Examples include Bitly, TinyURL, Rebrandly, Short.io, and similar platforms. Link shortening service A platform that provides URL shortening along with related features such as analytics, custom domains, QR code generation, link editing, campaign tracking, security scanning, and team management. The term emphasizes the full-service layer around short links rather than the shortening function alone. Link management platform A system for creating, organizing, tracking, securing, and managing links at scale. Link management platforms typically include URL shortening, branded domains, analytics, routing rules, bulk operations, QR codes, integrations, permissions, and reporting. Domain The registered web address used in a URL. In `https://sho.rt/abc123`, the domain is `sho.rt`. URL shortening services may offer shared default domains and allow customers to configure custom domains for branded short links. [1] TLD / Top-level domain The final segment of a domain name, such as `.com`, `.org`, `.io`, or `.ly`. Short-link brands often choose short or memorable TLDs, but the choice of TLD can affect user trust, brand perception, cost, and availability. [1] Root domain / Apex domain The base registered domain without a subdomain, such as `example.com`. Some shorteners support using an apex domain for short links, while others recommend a subdomain such as `go.example.com` to avoid interfering with the main website. [1] Custom domain A domain owned or controlled by the user and configured to serve short links instead of using the shortening service's default shared domain. Custom domains improve brand recognition, user trust, and long-term portability. Example: using `go.yourcompany.com` instead of `bit.ly`. Branded domain A custom domain chosen specifically to reinforce a company, product, campaign, or organization identity. Branded domains are often short, memorable, and aligned with the brand name. Functionally, they are custom domains with a branding purpose. Subdomain A prefix added before a root domain, separated by a dot. In `go.yourcompany.com`, `go` is the subdomain. Subdomains are commonly used for short links because they let organizations create branded link namespaces without changing their main website domain. [1] Path The portion of a URL that follows the domain and identifies a location, resource, or route. In `https://example.com/products/shoes`, `/products/shoes` is the path. In a short link, the path often consists only of the slug, such as `/abc123`. [1] Query string The portion of a URL beginning with `?` that contains key-value parameter pairs. Example: `?color=blue&size=medium`. Query strings are commonly used for tracking, filtering, search state, personalization, and feature flags. Link shorteners may preserve, append, merge, or strip query strings depending on configuration. [1] URL parameters Individual key-value pairs within a query string, separated by `&`. Example: `utm_source=newsletter`. URL parameters are widely used for analytics, campaign attribution, personalization, product filtering, and application behavior. [1] Fragment / Anchor The portion of a URL following a `#` symbol, used by browsers to navigate to a specific section or state within a page. Example: `https://example.com/page#section-3`. Fragments are processed by the browser and are not sent to the server in normal HTTP requests, which can affect how they interact with redirects and tracking. [1] Protocol / Scheme The first part of a URL that indicates how the resource should be accessed. Common examples include `http://`, `https://`, `mailto:`, and custom app schemes such as `myapp://`. Short links nearly always use HTTPS for security and trust. [1] HTTP Hypertext Transfer Protocol, the standard protocol used by browsers and web servers to exchange web content. Plain HTTP is not encrypted, so modern browsers may warn users when forms, logins, or sensitive pages are served over HTTP. [2] HTTPS HTTP Secure, which uses TLS encryption to protect data in transit between a browser and a server. Reputable link shortening services serve short links over HTTPS to protect users, support modern browser expectations, and improve trust. [2] [3] Canonical URL The "official" version of a web address for a piece of content. When multiple URLs — including short links, tracked links, or slight variations — all point to the same page, the canonical URL is the one that search engines and analytics tools should treat as the primary address. Declaring a canonical URL helps avoid confusion or duplicate-content issues in search rankings. [4] URL encoding / Percent encoding The process of converting characters that can't safely appear in a web address into a standardized stand-in format. For example, a space becomes `%20`, and an ampersand used inside a value gets converted so it isn't mistaken for a separator. This happens automatically in most tools, but it's worth knowing about when shortening URLs that contain tracking parameters or special symbols. [1] IDN / Internationalized domain name A domain name that uses characters outside the standard Latin alphabet, such as accented letters, Arabic, Chinese, or other scripts. While this helps with localization, it can also create security risks — some characters from other alphabets look nearly identical to familiar Latin letters, making it possible to create deceptive domains that appear to be legitimate ones. [5] ### Redirects & Routing Redirect The behind-the-scenes process that sends someone who clicks a short link to the actual destination page. When you visit a short link, your browser receives a quick instruction from the server saying "go here instead," then takes you to the destination — usually so fast you don't notice the step in between. [2] Location header A behind-the-scenes instruction included in a server's redirect response that tells the browser which URL to go to next. Users never see this directly — it's part of the technical exchange that makes redirects work. [2] 301 redirect / Permanent redirect A type of redirect that signals the move to a new address is permanent. Browsers and search engines may remember a 301 redirect and go directly to the destination on future visits, which can mean some clicks don't pass through the shortener. This also affects how search engines transfer ranking credit to the destination page. [2] 302 redirect / Temporary redirect A type of redirect that signals the destination may change in the future. Because browsers don't permanently memorize a 302, every click continues to pass through the shortener — which is why most link shortening services use 302 redirects by default. It also means the destination can be updated at any time without breaking the link. [2] 307 redirect / Temporary redirect with method preservation A temporary redirect that preserves the exact type of request being made. This is mainly relevant for developers building integrations — for everyday link shortening, a standard 302 redirect is used instead. [2] 308 redirect / Permanent redirect with method preservation A permanent redirect that also preserves the exact type of request being made. Like the 307, this is mainly relevant in technical or developer contexts rather than everyday link management. [2] Meta refresh redirect A redirect triggered by an instruction embedded in a web page itself, rather than by the server. The page tells the browser "go to this other address in X seconds." This method is slower and less reliable than a server-side redirect and is rarely used by modern link shortening services. [4] JavaScript redirect A redirect triggered by code running in the browser. It can support complex logic but is generally slower and less reliable than a server-side redirect — and it won't work for users who have JavaScript disabled or for bots and search engine crawlers. Server-side redirect A redirect handled by the server before any page content is sent to the browser. The server simply says "go here" and the browser follows. This is the fastest and most reliable method, and it's what virtually all link shortening services use. [2] Client-side redirect A redirect that happens inside the browser after part of a page has already loaded, typically through JavaScript or a meta refresh instruction. These are slower and less consistent than server-side redirects. Redirect chain A sequence of multiple redirects needed to reach the final destination. Example: short link -> tracking link -> affiliate network -> landing page. Redirect chains increase latency, complicate analytics, and can reduce reliability. Best practice is to minimize unnecessary hops. Redirect loop An error condition in which one URL redirects back to itself or to another URL that eventually redirects back again, creating an infinite cycle. Browsers usually stop after a limited number of redirects and display an error. [2] Pass-through redirect A redirect that automatically carries any extra tracking information from the short link over to the destination URL. For example, if someone shares your short link with a campaign code appended, that code gets passed along to the landing page automatically. Parameter forwarding The process of copying tracking values or other information from the short link's address to the destination URL. Platforms may let you forward all values, only selected ones, or merge them with values already on the destination. Cloaking When a short link hides or obscures the true destination from the person clicking it. All short links do this to some degree by design — you can't see the full destination before clicking. The term has a negative meaning when it's used deliberately to hide harmful, deceptive, or policy-violating destinations. Preview pages, branded domains, and destination scanning help reduce this risk. Link forwarding A general term for sending someone from one web address to another. In link shortening, it simply means redirecting a short link to its destination URL. Deep link A link that takes users directly to a specific piece of content — such as a product page, article, or account screen — rather than to a website's homepage. Deep links skip the homepage and drop the user exactly where they need to be. App deep link A deep link designed to open content inside a mobile app rather than in a browser. These links detect whether the app is installed and, if so, open the relevant screen directly inside the app. Deferred deep link A smart link that remembers where it was supposed to send someone, even if their app wasn't installed when they first clicked. The user is sent to download the app first, and once it's installed and opened, they're taken straight to the intended content. Commonly used in mobile marketing campaigns. Universal Link An Apple standard that allows a single web address to open either a specific screen inside an iOS app (if the app is installed) or a regular webpage (if it isn't). This creates a seamless experience without requiring separate links for app users and web users. [6] Android App Link Google's version of Universal Links for Android devices. A single web address can open a specific screen inside an Android app when the app is installed, or fall back to a webpage if it isn't. [7] Smart redirect A redirect that automatically sends different visitors to different destinations based on context — such as what device they're using, where they are in the world, or what time it is. A single short link might send iPhone users to the App Store, Android users to Google Play, and desktop users to a website. Device-based redirect A smart redirect that routes visitors to different destinations based on the type of device or operating system they're using — such as desktop, iPhone, or Android. Geo-targeting redirect A smart redirect that sends visitors to different destinations based on their location, such as their country, region, or city. Commonly used to show localized offers, the right language version of a page, or region-specific content. Language-based redirect A smart redirect that routes visitors to different destinations based on the language their browser is set to. This helps send users to the version of a page that's written in their preferred language. Time-based redirect A redirect that changes where it sends people based on the date or time. Useful for countdown campaigns, event registrations that close at a deadline, flash sales, or post-event pages that replace the original destination automatically. Rules engine A system inside a link management platform that evaluates conditions — like device type, country, language, time, or where the click came from — and decides which destination to send the visitor to. Rules engines power smart redirects and complex routing logic without requiring code. Fallback URL A backup destination that receives visitors when the primary destination isn't available, has expired, or doesn't match any routing rules. Fallback URLs prevent dead ends and help ensure visitors always land somewhere useful. Destination override A rule that changes the default destination of a link under specific conditions, such as when a certain parameter is present, when the visitor is in a particular location, or when a campaign has ended. Interstitial page A page shown briefly between a short link and its final destination. Interstitial pages might display a branded transition, a safety notice, an age gate, a password prompt, or a preview of the destination before the visitor continues. ### Analytics & Tracking Click tracking The process of recording data each time someone clicks a short link. This typically captures when the click happened, what device was used, roughly where in the world the person was, what website or app they came from, and other useful details. Click count The total number of times a short link has been clicked within a given period. This is the most basic measure of link activity, though it may include repeat clicks and automated traffic unless filtered. Total clicks The raw count of all click events recorded for a short link, including repeat visits from the same person and automated traffic. Total clicks show overall volume but may be higher than the number of actual people reached. Unique clicks An estimate of how many distinct individuals clicked a link. Because it's difficult to identify people with certainty online, this is typically estimated using a combination of IP address, browser information, and other signals. Treat this as a useful approximation rather than an exact count. Raw clicks All click events recorded before any filtering or cleaning. Raw clicks may include real visitors, automated bots, security scanners, duplicate clicks, and internal testing activity. Filtered clicks Clicks remaining after the platform removes known bots, duplicate events, internal traffic, and other activity that doesn't represent genuine visitors. Filtered clicks give a cleaner picture of real human engagement. Human clicks Clicks that the platform has determined are most likely from real people rather than automated systems. This classification uses signals like browser behavior, IP reputation, and device patterns — it's a best estimate, not a guarantee. Click-through rate (CTR) The percentage of people who see a link and actually click it. Calculated as clicks divided by impressions, multiplied by 100. CTR is widely used to measure how compelling a message, ad, or call to action is. Impression A single instance of a link, ad, or post being displayed to someone. CTR is calculated using impressions as the baseline. Link shorteners can track clicks, but they can't always measure impressions — that data usually comes from the platform where the link was shown. Referrer / Referring URL The website or app that a visitor came from before clicking a short link. For example, if someone clicks your link in a newsletter, the referrer might show as your email platform. Note that privacy settings, certain apps, and browser policies sometimes hide this information, causing clicks to show up as "direct" or "unknown." [2] Traffic source The channel or origin that sent visitors to a short link — such as email, social media, paid advertising, or a partner website. Traffic source is typically identified through referrer data, UTM parameters, or click IDs. Direct traffic Clicks where no referrer information is available. This can happen when someone types a URL directly, clicks a link in a messaging app, copies and pastes a link, or visits from an environment that strips referrer data. Direct traffic is often larger than expected for this reason. Geographic data / Geo data Location information inferred from a visitor's IP address at the time of a click. It typically includes country, region, and city. This is an approximation — VPNs, shared networks, and mobile carriers can affect accuracy. Browser data Information about which browser or app was used to click a short link, such as Chrome, Safari, or Firefox. This comes from information the browser sends automatically with each request. Device type The category of device used to click a link — such as desktop computer, mobile phone, or tablet. Device data helps with understanding your audience and setting up smart redirect rules. Operating system The software running on the visitor's device, such as Windows, macOS, iOS, or Android. This is often used alongside device type to understand your audience or route mobile users to the right app store. User agent A string of text that browsers and apps automatically send with every web request, describing what software and device is being used. Link platforms use this to determine device type, browser, and operating system — and to help identify bot traffic. User agents can sometimes be incomplete or altered for privacy. [2] IP address A number that identifies the device or network making a request. Link shorteners use IP addresses to estimate location, detect bots, count unique visitors, and enforce security rules. IP addresses can be shared among many users (like on a corporate network) or hidden by a VPN, and may be considered personal data under privacy laws in some regions. [8] Time of click The date and time recorded when a click event occurs. Platforms typically store this in a universal time standard and display it in your account's time zone. Time-of-click data helps you understand when your audience is most active. Session A period of user activity grouped together by an analytics system. Link shorteners track individual clicks; session-level data (like pages visited after clicking) is usually captured by the analytics platform on the destination website. Conversion A meaningful action taken by a visitor after clicking a link — such as making a purchase, signing up, downloading a file, or submitting a form. Conversions are the ultimate measure of whether a link campaign actually achieved its goal. Conversion tracking The process of measuring how many people who clicked a link went on to complete a desired action. This typically requires adding a small tracking snippet to the destination page or connecting the shortening service to an analytics or advertising tool. Post-click tracking Tracking what visitors do after they land on the destination page — such as browsing, filling out a form, or making a purchase. This requires instrumentation on the destination website and is separate from what the link shortener records. Attribution window The time period during which a click can receive credit for a later conversion. For example, a 7-day attribution window means a link click gets credit for a purchase if it happens within seven days of the click. Engagement rate A measure of how meaningfully visitors interact with content, beyond simply clicking a link. Depending on the tool, engagement rate might factor in time spent on page, how far they scrolled, whether they converted, or other actions. Link performance An overall assessment of how well a link is doing. This typically includes clicks, estimated unique visitors, conversion rate, geographic reach, device mix, and campaign attribution data. Dashboard The main screen in a link management platform where you can see analytics, manage your links, monitor campaign results, and access settings. Dashboards typically show top-level metrics like total clicks over time, your most-clicked links, where visitors came from, and what devices they used. Real-time analytics Analytics data that updates within seconds of a click occurring. Real-time analytics are especially useful during live events, product launches, or time-sensitive campaigns where you need to react quickly. Historical data Stored analytics data from past activity. Historical data lets you compare performance across time periods, identify trends, and evaluate the long-term impact of campaigns. How far back data goes depends on your plan and provider. Bot traffic Clicks generated by automated programs rather than real people. Bots include search engine crawlers, link preview generators, email security scanners, and malicious scripts. Unfiltered bot traffic inflates click numbers and skews analytics. Bot filtering The process of identifying and separating bot-generated clicks from real human activity. Platforms use signals like browser behavior, known bot lists, IP reputation, and request patterns to filter out automated traffic. Invalid traffic Clicks or activity that don't represent genuine visitor engagement — including bots, duplicate clicks, fraudulent traffic, and accidental reloads. Filtering invalid traffic gives a more accurate picture of real campaign performance. Click deduplication The process of identifying and handling repeated clicks from the same person, device, or bot within a set time window. Deduplication helps distinguish how many times a link was clicked from how many individual people clicked it. Internal traffic filtering Excluding clicks from your own team, agency, or office network from analytics reports. Without this, testing links, reviewing campaigns, and employee activity can inflate your click data. Event stream A chronological log of activity related to a link — including clicks, edits, expirations, and other platform events. Event streams are useful for monitoring, automation, and connecting link data to other business systems. ### UTM Parameters & Campaign Tracking UTM parameters A set of short labels you can add to the end of a web address to tell your analytics tools where a click came from and which campaign drove it. UTM stands for Urchin Tracking Module — named after an early analytics company that later became Google Analytics. When you shorten a URL that includes UTM labels, those labels are preserved and passed along to the destination, where your analytics platform reads them. [9] UTM source The `utm_source` label, used to identify where the click came from — such as a specific newsletter, social platform, or partner site. Examples: `newsletter`, `linkedin`, `google`, `spring_email_list`. [9] UTM medium The `utm_medium` label, used to identify the type of marketing channel. Examples: `email`, `paid_social`, `cpc` (paid search), `affiliate`, `qr`. [9] UTM campaign The `utm_campaign` label, used to name the specific campaign or promotion. Examples: `spring-launch`, `black-friday-2026`, `product-announcement`. [9] UTM term The `utm_term` label, traditionally used in paid search ads to note which keyword triggered the ad. It can also be used in other contexts when you want to track a specific term or audience segment. [9] UTM content The `utm_content` label, used to tell apart different links within the same campaign — for example, two different buttons in the same email, or two ad creatives in the same campaign. Example values: `hero-button`, `footer-link`, `blue-creative`. [9] UTM ID / Campaign ID The `utm_id` label, used to tag a campaign with a stable, unique identifier. Useful when campaign names might change or when you need a consistent ID to connect data across different tools. [9] UTM builder A tool that helps you create properly formatted campaign URLs by filling out a simple form — so you don't have to type UTM labels manually and risk mistakes. Most link management platforms include a built-in UTM builder. Campaign URL A destination web address that includes UTM labels for tracking. Campaign URLs are often long and messy, which is why they're typically shortened before being shared. Campaign tagging The practice of adding UTM or other tracking labels to links before distributing them. Consistent tagging across all your campaigns makes it possible to accurately compare channel performance in your analytics reports. UTM naming convention An agreed-upon set of rules for how your team writes UTM values — including capitalization, punctuation, source names, and campaign formats. Without a naming convention, the same source might appear as `Email`, `email`, and `e-mail` in your reports, splitting data that should be combined. UTM governance The process of defining, documenting, and enforcing your UTM naming rules across teams, agencies, and tools. Good governance keeps analytics data clean and consistent as your organization grows. Channel grouping A way of organizing web traffic into broad categories like Email, Paid Search, Organic Social, or Referral. Channel groupings are usually defined in your analytics platform and rely on UTM source and medium values to sort traffic correctly. Auto-tagging When an advertising platform automatically adds its own tracking identifiers to URLs rather than requiring you to add them manually. Google Ads and Meta do this by default. Auto-tagging needs to be coordinated with any manual UTM tagging to avoid conflicts. [10] GCLID / Google Click Identifier A tracking code that Google Ads automatically adds to URLs when someone clicks a Google ad. It helps connect the ad click to conversions and analytics data in Google's platforms. [10] FBCLID A tracking identifier that Meta (Facebook and Instagram) sometimes adds to outbound links. It's used for attribution within Meta's advertising systems. Many analytics teams choose to filter it out to keep URLs clean. MSCLKID A tracking identifier added by Microsoft Advertising (formerly Bing Ads) when auto-tagging is enabled. It works similarly to Google's GCLID, connecting ad clicks to conversion data. [11] Click ID A unique identifier tied to a specific click event. Click IDs are often appended to destination URLs so that advertising platforms, affiliate networks, or analytics systems can match the click to a later conversion. Attribution The process of figuring out which marketing touchpoints deserve credit for a conversion. Attribution answers the question: "Which link, ad, or campaign actually drove this result?" First-touch attribution An attribution model that gives all the credit for a conversion to the very first link or touchpoint a person interacted with. Useful for understanding what first introduced someone to your brand or product. Last-touch attribution An attribution model that gives all the credit to the final link or touchpoint before a conversion. Simple to implement, but it ignores all earlier interactions that may have influenced the decision. Multi-touch attribution An attribution approach that spreads credit for a conversion across multiple touchpoints in a person's journey. Common models include giving equal credit to all touchpoints, giving more credit to recent ones, or giving extra weight to the first and last interactions. Pixel tracking A method of tracking visitor behavior by placing a tiny, invisible image or small piece of code on a web page. When someone visits the page, it quietly sends data to an analytics or advertising platform. Pixels are commonly used for conversion tracking and building retargeting audiences. Retargeting pixel A tracking pixel that adds visitors to an advertising audience so you can show them follow-up ads later. For example, if someone clicks your short link and visits your product page, a retargeting pixel can add them to a list for a follow-up ad campaign. Tag A word with different meanings depending on context. In analytics and advertising, a tag is a tracking pixel or script placed on a web page. In a link management platform, a tag is an organizational label you apply to links to group and filter them. In UTM tracking, a tag refers to the UTM parameters themselves. Tag manager A tool like Google Tag Manager that lets you add and manage tracking scripts and pixels on a website through a simple interface — without needing to edit the website's code directly every time. ### QR Codes & Physical Media QR code A square barcode made up of black and white patterns that encodes information — most commonly a web address. Smartphones can scan QR codes using their camera and instantly open the encoded URL, making QR codes a popular bridge between physical materials and digital content. [12] Dynamic QR code A QR code that points to a short link rather than directly to a final destination. Because the short link's destination can be updated at any time, you can change where the QR code sends people without reprinting it. Dynamic QR codes also support scan tracking. Static QR code A QR code that is permanently encoded with a specific destination. Once printed, a static QR code cannot be changed — if the destination moves, you need a new QR code. Static codes generally don't provide scan tracking unless they point to a tracked URL. [12] QR code generator A tool that creates QR codes from URLs or other data. Most link management platforms include a QR code generator and may offer customization options like colors, logos, file formats, and campaign tracking. QR code scan The act of pointing a smartphone camera at a QR code to decode it and open the encoded URL. When a dynamic QR code routes through a trackable short link, each scan is recorded as a click event. Print-to-digital Using QR codes, short URLs, or similar tools on physical materials — like brochures, packaging, posters, or business cards — to send people to a digital experience. Print-to-digital makes physical marketing measurable. Offline-to-online The broader practice of moving people from physical-world touchpoints into digital experiences. Link management tools make these transitions trackable through QR codes, short URLs, and NFC tags. Scan rate The number of times a QR code has been scanned in a given period, or the percentage of scans relative to estimated views or impressions. Scan rate is a key metric for measuring the effectiveness of print, packaging, and out-of-home campaigns. QR customization The ability to change how a QR code looks — such as its colors, the logo in the center, or the shape of its corner markers — while keeping it scannable. Good customization stays on-brand while maintaining enough contrast and structure to be read reliably by cameras. [12] Error correction level A setting that determines how much of a QR code can be damaged, obscured, or covered by a logo and still be scanned successfully. Higher error correction allows more visual modification but may make the code denser and slightly harder to read at small sizes. [12] QR eye / Finder pattern The three large square markers in the corners of a QR code that help cameras detect, orient, and decode it. These are often customized with rounded shapes or brand colors while still allowing reliable scanning. [12] Quiet zone The blank border of white space around the outside of a QR code. This margin helps cameras find and read the code. Cropping into the quiet zone is a common cause of scanning failures. [12] Scannability How easily and reliably a QR code can be scanned in real-world conditions. Good scannability depends on size, contrast between light and dark areas, print quality, the surface it's printed on, available lighting, and whether the quiet zone is intact. [12] NFC tag A small chip embedded in a physical object — like a sticker, card, or product — that can trigger an action, such as opening a web address, when a compatible smartphone is tapped against it. NFC tags are often used alongside QR codes as another way to connect physical items to digital experiences. [13] ### Link Management Features Link editing / Destination editing The ability to change where a short link points after it's already been created and shared. This is one of the biggest advantages of managed short links — if a landing page moves or a campaign changes, you can update the destination without touching the link itself. Link expiration A feature that automatically turns off or reroutes a short link after a set date, time, or number of clicks. Useful for time-sensitive promotions, event registrations with a deadline, or temporary access links. Expiry date The date and time when a short link is set to stop working or change behavior. Setting an expiry date means the link handles its own deactivation automatically when the campaign ends. Link deactivation Turning off a short link so it no longer redirects visitors. Deactivated links can usually still be seen in the platform for record-keeping and analytics, even though they no longer work for end users. Link rotation A feature that distributes clicks across multiple destination URLs from a single short link. Clicks can be split evenly, randomly, or by custom percentages. Useful for testing different landing pages, distributing leads, or running promotions across multiple offers. A / B testing / Split testing An experiment where traffic from a single short link is split between two or more different destination pages to see which one performs better. The winner is determined by whichever version generates more clicks, conversions, or other desired actions. Weighted redirect A link rotation setup where traffic is divided by percentage rather than equally. For example, you might send 70% of visitors to one page and 30% to another — useful for gradual rollouts or carefully controlled experiments. Password-protected link A short link that asks visitors to enter a password before they can access the destination. Used for private content, internal previews, partner materials, or events where access should be limited. Link preview A snapshot of what a link leads to, shown before or instead of an immediate redirect. This can mean the social media card that appears when a link is shared, or an interstitial page hosted by the shortener that shows the destination before the visitor continues. Social preview / OG preview The title, description, and thumbnail image that appear when you share a link on social media, messaging apps, or collaboration tools. Platforms like LinkedIn, Twitter/X, Slack, and iMessage generate these previews automatically from information embedded in the destination page. Open Graph / OG tags Hidden tags in a web page's code that tell social platforms what title, description, and image to use when generating a link preview. Some link management platforms let you customize these values on the short link itself, overriding whatever the destination page specifies. [19] Twitter Card / X Card A set of hidden tags in a web page's code that control how a link appears specifically when shared on X (formerly Twitter). Different card formats support a text summary, a large image, an app download prompt, or a media player. [20] Link-in-bio A simple page accessible through a single URL — typically placed in a social media profile bio — that collects multiple links in one place. Because platforms like Instagram only allow one clickable link in your profile, a link-in-bio page lets you direct followers to several destinations from that one spot. Link page A page hosted by a link management platform that displays one or more links. Link pages can function as link-in-bio pages, campaign hubs, event landing pages, or lightweight microsites. Landing page The webpage a visitor arrives on after clicking a campaign link. This is typically a page created by a marketer to match the message of a specific campaign. A landing page is hosted on a website and is distinct from a link page hosted by the shortening platform. Bulk link creation The ability to create many short links at the same time — typically by uploading a spreadsheet, using the API, or applying a template. Essential for large campaigns, product catalogs, field teams, and direct mail programs. Bulk edit The ability to update multiple links at once — such as changing destinations, adding tags, moving to a different folder, or updating expiration dates — without editing each link individually. Link import / export Tools that let you bring existing links into a platform or extract your link library as a file for backup, migration, reporting, or use in other tools. These typically use spreadsheet or CSV formats. Tags & labels Keywords or labels you can attach to links inside the platform to keep them organized. Tags make it easy to filter, search, and report on links by campaign, channel, team, region, or any grouping that makes sense for your workflow. Folders / Workspaces Organizational containers for grouping links. Folders typically organize links within a project or campaign, while workspaces often separate different teams, clients, or brands — sometimes with their own access controls. Link ownership The user, team, or workspace responsible for a link. Ownership determines who can edit the link, who sees it in their dashboard, and who is accountable for how it's used. Link transfer Moving a link from one owner, folder, workspace, or account to another. Useful when team members change, when agencies hand off work to clients, or when consolidating accounts. Link history / Audit trail A log of everything that's happened to a link — including when it was created, who changed it, what the destination was changed to, and any routing or expiration updates. Audit trails are valuable for accountability, compliance, and troubleshooting. Approval workflow A process that requires a link to be reviewed and approved before it goes live or is distributed. Approval workflows help organizations ensure that links are correct, on-brand, and compliant before they reach an audience. Template link A saved configuration that can be used to quickly create new links with consistent settings — such as a standard domain, UTM parameters, folder assignment, or expiration rules. Templates reduce repetitive setup and help maintain consistency across a team. Case sensitivity Whether the platform treats uppercase and lowercase letters in a slug as the same or different. For example, does `/Sale` lead to the same place as `/sale`? This affects how links behave if someone types them manually and how duplicates are handled. Link archive A collection of old, expired, or retired links kept in the platform for reference and historical reporting. Archived links typically no longer redirect but their data and settings are preserved. Favorites / Starred links A way to bookmark specific links in the dashboard for quick access. Useful for keeping frequently monitored or high-priority links easy to find without searching. Notes / Descriptions A free-text field on a link record where you can write notes for yourself or your team — such as what the link is for, which campaign it belongs to, who's responsible, or any special instructions. Link health / Uptime monitoring Automated checks that regularly verify a short link's destination is reachable and working. If the destination page goes down or returns an error, the platform can send an alert so you can fix the problem before too many visitors are affected. Broken link detection The process of finding short links whose destinations are returning errors, have been removed, or are no longer accessible. Catching broken links quickly prevents visitors from hitting dead ends. 404 fallback A backup destination that visitors are sent to when a short link no longer works — for example, if it has expired or been deactivated. Instead of showing a generic "page not found" error, you can route visitors to your homepage, a search page, or a helpful custom message. ### Security, Trust & Compliance Secret link / Secret URL A link that delivers a sensitive payload — a password, API key, token, or private note — instead of redirecting to a public destination. Secret links typically combine access controls such as single-view enforcement, expiration windows, and passphrase protection, and destroy the payload after delivery so the sensitive value does not persist in inboxes, chat history, or server logs. Unlike a regular short link, the URL itself is the delivery mechanism and dies after it has done its job. One-time link / One-time secret A secret link that can be successfully opened exactly once. The first successful view atomically consumes the link: the payload is destroyed and every subsequent request receives a dead-link response. One-time semantics protect against forwarding, replay, and later compromise of the channel the link was sent through. The terms one-time link, one-time secret, and burn-after-read all describe the same behavior. Burn-after-read / Burn after reading The destruction model behind one-time links: the moment the content is first revealed, it is permanently deleted ("burned") from the service's storage. A burned link cannot be recovered by the sender, the recipient, or the operator — non-recoverability is the security property, not a limitation. Services often distinguish burning (consumed by a view) from expiry (destroyed by a deadline passing unviewed). Self-destructing link An umbrella term for links that stop working automatically — either after a set number of views (burn-after-read) or when an expiration deadline passes. Self-destruction limits how long a leaked or forwarded URL stays dangerous and is the core control that separates secret-sharing links from ordinary short links. Passphrase-protected link A secret or short link that requires a shared passphrase before the content is revealed or the redirect fires. Because the passphrase is communicated out-of-band (a different channel than the link itself), an intercepted URL alone is not enough to expose the content. Well-implemented services hash the passphrase in the recipient's browser rather than transmitting it in cleartext. SSL / TLS / HTTPS SSL and TLS are the security technologies that encrypt data traveling between your browser and a website, protecting it from being intercepted. HTTPS in a web address means that encryption is active. All reputable link shortening services use HTTPS to keep users safe and signal that a link is trustworthy. [3] TLS certificate A digital credential that enables a website to use HTTPS. When you set up a custom domain for short links, the link management platform typically handles obtaining and renewing this certificate for you. [3] Link security The overall set of measures that ensure short links aren't used to deceive or harm the people who click them. This includes using HTTPS, scanning destination URLs for malicious content, detecting phishing, enforcing acceptable use policies, and giving users tools to report problems. Phishing A scam where someone tricks you into visiting a fake website — usually designed to look like a trusted brand — to steal your password, payment details, or other sensitive information. Short links are sometimes misused in phishing because they hide the real destination. Link platforms actively scan for and block phishing links. Link spam The use of short links in unwanted or deceptive communications — like mass spam emails, fake social media posts, or comment spam on websites. Link spam damages the reputation of the domain used and can cause links to be flagged or blocked by email providers and browsers. Malicious link A short link that leads to a harmful destination — such as a website that installs malware, harvests credentials, runs a scam, or hosts prohibited content. Malware scanning Automated checks that inspect a link's destination for harmful software, suspicious scripts, or known dangerous content before the link is created or while it remains active. Safe browsing A category of protection systems that check web addresses against databases of known harmful sites. Google Safe Browsing is one widely used example. Link platforms may use these services to screen destinations and warn users about risky links. [14] Link scanning Automated checks performed on a short link's destination — at creation time, at click time, or periodically — to detect malware, phishing, policy violations, or broken pages. Threat intelligence Information used to identify risky websites, domains, or online behaviors. Link platforms use threat intelligence from their own systems and external security providers to catch harmful links before they reach users. Phishing detection The process of identifying links designed to impersonate trusted brands, steal credentials, or mislead users. Detection looks at factors like visual similarity to known brands, suspicious domain names, and patterns associated with scam campaigns. Lookalike domain / Homograph attack A scam technique that uses a domain name designed to visually resemble a well-known and trusted one — for example, replacing a lowercase `l` with the number `1`, or using a character from another alphabet that looks identical. These fake domains are used in phishing and fraud campaigns. [5] Blocklist / Blacklist A list of domains, web addresses, or other identifiers known or suspected to be harmful or abusive. Link platforms use blocklists to prevent short links from pointing to dangerous destinations. "Blocklist" is the modern preferred term; "blacklist" is an older synonym. Allowlist / Whitelist A list of approved destinations, users, or actions that are explicitly permitted. Some enterprise link platforms use allowlists so that employees can only create short links pointing to approved company domains. "Allowlist" is the modern preferred term; "whitelist" is an older synonym. Domain reputation A measure of how trustworthy a domain is, based on its history with spam, phishing, malware, and other signals. A domain with a poor reputation may cause links to be flagged by email providers, blocked by browsers, or distrusted by users. Abuse report A report submitted by a user, researcher, or automated system flagging a short link as potentially harmful, deceptive, or in violation of platform policies. Abuse reports trigger investigation and potential removal of the offending link. Abuse prevention The combination of automated tools and human review processes that a link platform uses to detect and stop misuse — including spam, phishing, malware distribution, and policy violations. Suspended link A short link that has been disabled by the platform because it violated policies, was involved in abuse, was flagged for legal reasons, or was associated with an account with billing issues. Visitors to a suspended link typically see a warning or error page. GDPR compliance Following the rules of the General Data Protection Regulation, a European law that governs how personal data about individuals is collected, used, and stored. For link management platforms, this affects how click data — including IP addresses and location — is handled, and it requires mechanisms for user consent and the ability to delete personal data on request. [8] CCPA / CPRA compliance Following California's privacy laws, which give California residents rights over their personal information — including the right to know what data is collected, to opt out of data sharing, and to request deletion. Link platforms that collect click and device data need to address these requirements for California users. [15] Cookie consent The process of asking users for permission before placing cookies or similar tracking tools on their device — required by privacy laws in many countries. Link platforms that use cookies for analytics or advertising may need to present a consent notice to users in affected regions. [8] Consent management The systems and processes used to collect, store, and honor user consent preferences for data collection, cookies, tracking pixels, and advertising. Consent management becomes important when link tracking goes beyond basic server-side click logs. [8] Privacy policy A public document that explains what data a platform collects, how it's used, who it's shared with, how long it's kept, and what rights users have. Link management platforms publish privacy policies that describe how click analytics and account data are handled. [8] Data retention How long a platform keeps click data, analytics, and other records. Retention periods vary by provider and plan — some keep data for 30 days, others for years. Shorter retention can support privacy best practices by not keeping data longer than necessary. [8] Data processing agreement / DPA A formal contract between an organization and a software vendor that specifies how the vendor will handle personal data on the organization's behalf. DPAs are common in enterprise relationships and are particularly important for GDPR compliance. [8] Data residency The requirement or preference that data be stored and processed within a specific country or region. This matters for regulated industries, government organizations, and companies with regional data compliance obligations. [8] PII / Personal data Information that can be used to identify a specific individual. In link analytics, this may include IP addresses, device identifiers, location data, and click-level logs, depending on the jurisdiction and how the data is combined or used. [8] Terms of service The legal agreement between a link management platform and its users. It defines what you can and can't do with the platform, what content and destinations are prohibited, and what happens if the rules are broken. Rate limiting A control that caps how many requests a user, IP address, or application can make within a given time period. Rate limiting protects the platform from abuse, automated attacks, and overload — and ensures fair access for all users. CAPTCHA A challenge — like identifying objects in photos or checking a box — used to verify that a request is coming from a real person rather than an automated bot. Link platforms may use CAPTCHAs during sign-up or when suspicious activity is detected. [16] Two-factor authentication / 2FA A login security feature that requires two forms of verification to access your account — typically your password plus a one-time code sent to your phone or generated by an app. 2FA makes it much harder for someone to access your account even if they know your password. Single sign-on / SSO A way to log into a link management platform using the same credentials you use for other work tools — like Google Workspace, Microsoft, or Okta — rather than a separate username and password. SSO simplifies access management, especially for large teams. Role-based access control / RBAC A system that assigns team members different levels of access based on their role. For example, an admin might be able to create and delete links, while a viewer can only read reports. RBAC ensures people can only do what their job requires. ### API, Integrations & Technical Infrastructure API / Application Programming Interface A way for software applications to communicate with each other. A link management platform's API lets developers build their own tools, automate link creation, pull analytics data, and integrate the platform into other systems — all without using the web interface manually. API key A private code used to prove your identity when making API requests. Think of it like a password for your application. API keys should be kept secret, monitored, and changed if they're ever exposed. Access token A temporary credential used to authorize API requests. Access tokens often have defined permissions and expiration times, making them slightly more secure than long-lived API keys for certain integrations. [17] OAuth A widely used standard that lets you grant third-party apps access to your account without sharing your password. When you click "Sign in with Google" or "Connect your account" in a platform, you're typically using OAuth. [17] REST API A common style of building APIs that uses standard web methods — like GET to retrieve data, POST to create something, PUT or PATCH to update, and DELETE to remove — applied to specific URLs. Most link management platforms offer REST APIs. [2] Endpoint A specific URL within an API that handles a particular action or resource. For example, one endpoint might create a new short link while another retrieves click analytics for a specific link. SDK / Software Development Kit A ready-made package of code that helps developers connect to an API using their preferred programming language. Instead of writing all the low-level web requests from scratch, an SDK provides pre-built functions and examples. Webhook An automatic notification your platform sends to another system when something happens — like a link being clicked, created, or expired. Instead of constantly checking for updates, your other tools receive a notification the moment an event occurs. Webhook signature A security code included with every webhook notification that lets the receiving system verify the message genuinely came from the link platform and wasn't tampered with in transit. Retry policy Rules that define what happens when an API call or webhook notification fails — such as how many times to try again, how long to wait between attempts, and what to do if all retries fail. Pagination A way of delivering large amounts of data in manageable chunks rather than all at once. When an API call would return thousands of links or click records, pagination splits the results into pages so each response stays fast and practical. Rate limit A cap on how many API requests can be made within a given time window — for example, 1,000 requests per hour. Exceeding the rate limit results in a temporary block until the window resets. Rate limits protect the platform and ensure fair access for all users. Zapier / Make integration Ready-made connectors that let you link your link management platform to hundreds of other apps without writing any code. For example, you could automatically shorten a URL whenever a new row is added to a spreadsheet, or post a notification to Slack when a link reaches a certain number of clicks. CMS integration A plugin or built-in connection that adds link shortening and tracking features directly into a content management system — such as WordPress or HubSpot — so you can manage short links without leaving your content editor. Browser extension A small add-on installed in your web browser that lets you shorten, copy, or manage the URL of the page you're currently viewing with a single click, without opening the link management platform separately. DNS configuration The process of setting up your domain's internet records so that your custom short-link domain points to the link management platform's servers. This is a required step before your custom domain can start serving short links. DNS propagation The time it takes for a DNS change to spread across the internet so that everyone's browsers and devices see the updated settings. Propagation usually takes a few minutes to a few hours, though it can occasionally take longer depending on settings and network caches. CNAME record A type of DNS record that points one domain name to another. For example, you might set up `go.yourcompany.com` to point to your link platform's servers using a CNAME record. [18] A record A type of DNS record that connects a domain name directly to a specific server's IP address. Some link platforms use A records instead of CNAME records when setting up custom domains — particularly for root domains like `yourcompany.com` rather than subdomains. [18] TXT record A DNS record used to store text-based information about a domain. Link platforms often ask you to add a TXT record to prove you own a domain before activating it for short links. [18] Domain verification The process of proving to a link management platform that you actually own or control a custom domain before it's activated. This usually involves adding a specific DNS record or file that the platform checks. CDN / Content Delivery Network A network of servers spread across many locations around the world that work together to deliver content faster. Link shortening platforms may use a CDN so that redirects are processed from a server close to the visitor, reducing the time it takes to reach the destination. Edge redirect A redirect handled by a server located close to the visitor — rather than at a central server far away — to make the redirect faster. Edge redirects are made possible by CDN infrastructure. Latency The delay between clicking a short link and arriving at the destination page. Lower latency means a faster, smoother experience. Latency is affected by server location, network speed, the number of redirect hops, and DNS lookup time. Uptime / SLA Uptime is how much of the time a service is operational and available. A Service Level Agreement (SLA) is a formal commitment from the provider specifying guaranteed uptime (e.g., 99.9%) and what remedies apply if that standard isn't met. For link shortening, downtime means every short link stops working — so uptime is critically important. Multi-region failover A design approach where traffic automatically shifts to backup servers in another location if one server or data center goes down. Multi-region failover improves reliability for high-volume or business-critical link campaigns. Caching Storing frequently used data — like which short link maps to which destination — in fast-access memory so it can be retrieved almost instantly without looking it up from scratch each time. Caching speeds up redirects significantly, though it can occasionally cause a slight delay when a destination is updated. Server log A record kept by the platform's servers of every request they process. For link shortening, server logs include timestamps, IP addresses, devices, browsers, and request details for every click. Logs are used for analytics, debugging, and compliance. ### Plans, Billing & Account Free plan A no-cost tier that gives you basic link shortening features with limits on how many links you can create, how many clicks are tracked, what analytics are available, and which features are accessible. Free plans are designed to let you try the platform before committing to a paid subscription. Paid plan / Subscription A recurring payment arrangement — billed monthly or annually — that unlocks higher limits, more features, deeper analytics, custom domains, team tools, and priority support. Annual plans typically cost less than paying month-to-month. Link limit The maximum number of short links an account can create or keep active under a given plan. Once the limit is reached, you may need to delete existing links or upgrade your plan to create more. Click limit The maximum number of click events included in a plan per billing period. When the limit is reached, the platform may keep redirecting visitors but stop recording analytics, or it may prompt you to upgrade. Overage Usage that goes beyond what your plan includes. Depending on the platform, overages may result in extra charges, reduced features, paused tracking, or a prompt to move to a higher plan. Team account / Organization account An account designed for multiple people working together. Team accounts include shared access to links and analytics, centralized billing, and tools for managing who can do what within the account. Member / Seat An individual user within a team or organization account. Pricing for team plans is often based on the number of seats, with options to add more members for an additional cost. White-label A setup that lets an agency, reseller, or enterprise customer offer link shortening under their own brand — with their logo, domain, and design — hiding any reference to the underlying platform provider. Reseller A business or individual that purchases link management services and offers them to their own customers, often under a white-label arrangement. Resellers include marketing agencies, SaaS companies, and managed service providers. Enterprise tier The highest level of service, designed for large organizations with complex requirements. Enterprise plans typically include high or unlimited usage, custom contracts, dedicated support, SSO, advanced access controls, compliance features, and custom integrations. Account owner The primary administrator of an account, responsible for billing, settings, user management, and overall account governance. The account owner typically has the highest level of access. Billing contact The person or email address that receives invoices, payment notices, and billing-related communications. The billing contact may be a different person from the account owner or technical administrator. Usage quota The defined limit on resources included in a plan — such as the number of links, clicks, custom domains, QR codes, team members, or API requests allowed per billing period. Analytics retention limit How far back your click data is available to view in the platform. A free plan might show only the last 30 days, while an enterprise plan might retain data for several years. This affects your ability to do historical reporting and compare campaigns over time. ## Blog articles (full text) ### URL Shortener API Comparison: Bitly, Dub, Short.io, TinyURL — https://uselinkpilot.com/blog/url-shortener-api-comparison Published: 2026-07-09 · By LinkPilot Team URL shortener APIs compared on auth, webhooks, SDKs, and plan gating. Dub leads on developer experience; LinkPilot is the only one with secret links. If your links are created by code — signup flows, campaign tooling, CLI scripts — the API is the product. This comparison looks at the API surface of the major shorteners the way a developer evaluates them: auth, limits, webhooks, SDKs, and what the pricing tier gates. Capabilities below are as published July 2026 — verify with each vendor's docs before integrating. ## Which URL shortener API should you use? **Dub for developer experience (open source, typed SDKs, modern docs), Bitly for enterprise-proven scale, Short.io for cheap volume with multiple domains, and LinkPilot if you want scoped API keys and signed webhooks on every paid plan — plus the only API in the category that also creates burn-after-read secret links.** ## How do the APIs compare at a glance? <table> <thead> <tr><th>Capability</th><th>Bitly</th><th>Dub</th><th>Short.io</th><th>TinyURL</th><th>LinkPilot</th></tr> </thead> <tbody> <tr><td>Auth model</td><td>OAuth / access tokens</td><td>API keys, typed SDKs</td><td>API keys</td><td>API tokens</td><td>Scoped keys (lp_live_*), hashed at rest</td></tr> <tr><td>Open source</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td></tr> <tr><td>Webhooks / events</td><td>Tier-dependent</td><td>Higher tiers</td><td>Available</td><td>Limited</td><td>Signed webhooks, paid plans</td></tr> <tr><td>API on which plans</td><td>Paid tiers</td><td>Free tier up (rate-limited)</td><td>Free tier up (rate-limited)</td><td>Paid</td><td>All paid plans</td></tr> <tr><td>Custom domains via API</td><td>Yes (paid)</td><td>Yes</td><td>Yes</td><td>Paid</td><td>Yes (paid)</td></tr> <tr><td>Secret / burn-after-read via API</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td></tr> </tbody> </table> ## What makes an API "good" in this category? Four things decide whether a shortener API stays pleasant after the proof-of-concept: 1. **Idempotent link creation.** Re-running a job shouldn't mint duplicate slugs. Look for upsert-by-slug or external-ID support. 2. **Honest rate limits.** Published numbers, per-key scoping, and 429s with Retry-After — not silent throttling. 3. **Event delivery.** Polling click counts doesn't scale; webhooks or event streams do. Check signature verification while you're at it. 4. **Key hygiene.** Scoped keys you can rotate per integration beat one god-token. (LinkPilot's keys are prefixed lp_live_ and stored SHA-256-hashed, so a database leak can't replay them.) ## Where does each vendor genuinely shine? **Bitly** has the most battle-tested API in the category — v4 has been stable for years, rate limits are documented, and enterprise support is real. The friction is that meaningful API usage sits on paid tiers and several capabilities are enterprise-gated. **Dub** is what most developers will enjoy most: open-source core, typed TypeScript SDK, clean REST design, modern docs. If you're building link infrastructure into a product, its conventions are the current state of the art. **Short.io** is a workhorse: straightforward key auth, multiple domains, and generous low-tier access. Docs are more utilitarian than Dub's, but the price/volume ratio is strong. **TinyURL** offers a simple API on paid plans for basic shortening — fine for scripts, thin for platforms. **LinkPilot** covers the standard surface — link CRUD with custom slugs and domains, privacy-first analytics retrieval, signed webhooks for click and link events — with two distinctions: API access is included on every paid plan rather than a higher tier, and the same workspace exposes **secret links** (burn-after-read credentials with audit timelines). If your automation ever needs to hand a human a password — provisioning flows, onboarding, support tooling — that second workflow saves you integrating a separate secrets service. Keys are managed from the dashboard's API Keys page, where current endpoint docs live. See [pricing](/pricing) for what each plan includes. ## Which should you pick? - **Building link features into your own product:** Dub, or LinkPilot if secret delivery is part of the flow. - **Enterprise campaign infrastructure:** Bitly. - **High-volume, budget-sensitive automation:** Short.io. - **Occasional scripting:** TinyURL or any free tier. Two related tools while you evaluate: our free [redirect checker](/tools/redirect-checker) traces the full hop chain your API-created links produce (useful for catching double-redirects that hurt performance), and the [URL shortener](/tools/url-shortener) lets you sanity-check LinkPilot's redirect behavior without writing a line of code. For the product-level comparisons behind this piece, see [LinkPilot vs Dub](/compare/linkpilot-vs-dub) and [LinkPilot vs Bitly](/compare/linkpilot-vs-bitly). Q: Which URL shortener has the best API? A: Dub has the strongest pure developer experience (open source, typed SDKs, modern docs). Bitly's v4 API is the most battle-tested at enterprise scale. LinkPilot's API adds scoped keys and webhooks on all paid plans plus a secrets workflow no other shortener API offers. Q: Is there a free URL shortener API? A: Most vendors expose their API on free or low tiers with rate limits — Dub and Short.io are commonly used free for small volumes, and TinyURL has a simple API on paid plans. Check each vendor's current limits; free API quotas change frequently. Q: Do URL shortener APIs support webhooks? A: Not universally. Webhooks for click or link events are the feature to check before committing — LinkPilot ships signed webhooks on paid plans, Dub offers event streaming on higher tiers, and others vary. Verify current capability with each vendor. Q: Can I create burn-after-read secret links via an API? A: Among general link shorteners, LinkPilot is the one that exposes both short links and burn-after-read secret links from the same workspace and API surface. Dedicated tools like Password Pusher also offer a secrets API without the shortener half. ### OneTimeSecret vs Privnote vs Password Pusher: Which Should You Use? — https://uselinkpilot.com/blog/onetimesecret-vs-privnote-vs-password-pusher Published: 2026-07-09 · By W. Miller A three-way comparison of the most popular secret-sharing tools — encryption, expiry, revocation, self-hosting, and where each one genuinely wins. These three tools answer the same question — "how do I send something sensitive as a link that stops working?" — with three different sets of trade-offs. Here's the honest three-way, plus when none of them is the right answer. ## Which of the three should you use? **Use Password Pusher if you're an IT or engineering team that wants view-count caps, deletable links, an API, and a self-host option. Use OneTimeSecret if you want the simplest trustworthy open-source tool for one-off text secrets. Skip Privnote for anything valuable — it's closed source and clone-site phishing against it is widely reported.** ## Feature-by-feature comparison <table> <thead> <tr><th>Feature</th><th>OneTimeSecret</th><th>Privnote</th><th>Password Pusher</th></tr> </thead> <tbody> <tr><td>Open source</td><td>Yes</td><td>No</td><td>Yes</td></tr> <tr><td>Self-hosting</td><td>Yes</td><td>No</td><td>Yes</td></tr> <tr><td>No-signup use</td><td>Yes</td><td>Yes</td><td>Yes</td></tr> <tr><td>Burn-after-read</td><td>Yes (single view)</td><td>Yes (single view)</td><td>Yes — configurable N views</td></tr> <tr><td>Passphrase option</td><td>Yes</td><td>Yes (password)</td><td>Yes</td></tr> <tr><td>Expiry window</td><td>Up to 14 days hosted</td><td>Days</td><td>Configurable, long windows supported</td></tr> <tr><td>Delete/revoke a link</td><td>Limited</td><td>No</td><td>Yes — deletable links</td></tr> <tr><td>File sharing</td><td>Limited / paid</td><td>No</td><td>Yes (file push)</td></tr> <tr><td>API</td><td>Yes (basic)</td><td>No</td><td>Yes — first-class</td></tr> <tr><td>Audit trail</td><td>Minimal</td><td>No</td><td>Limited</td></tr> <tr><td>Team workspaces / RBAC</td><td>No</td><td>No</td><td>Limited</td></tr> </tbody> </table> Details as published July 2026 — all three projects evolve; verify current specifics with each one. ## Where does OneTimeSecret win? Simplicity plus verifiability. It has done one thing well for over a decade, the code is public, and the hosted tier is fine for occasional use. If your entire requirement is "send a text secret once, with an optional passphrase," OneTimeSecret is the least-moving-parts answer. Its limits show up in teams: minimal audit visibility, limited file support, and no workspace concept. (Deeper dive: [best OneTimeSecret alternatives](/blog/best-onetimesecret-alternatives).) ## Where does Privnote win? Speed for throwaway notes — no signup, minimal UI, done. But it's the only closed-source tool of the three, so its encryption claims can't be independently checked, and its brand has attracted lookalike phishing clones documented in security reporting. We've written a full assessment in [is Privnote safe?](/blog/is-privnote-safe). For anything involving credentials or money, choose something else. ## Where does Password Pusher win? Operational features. View-count caps ("burn after 3 views") cover the it-might-get-opened-by-a-scanner case, links are deletable, there's a real API and CLI, a file-push module, and a well-trodden Docker self-host path. For an IT department standardizing on one tool, pwpush is usually the right open-source answer. What it lacks is a tenant model: no per-workspace RBAC or rolled-up audit reporting. (Head-to-head: [LinkPilot vs Password Pusher](/compare/linkpilot-vs-password-pusher).) ## When is none of them the right answer? When the question isn't "can I send this once?" but "can I prove what happened, and undo it?" — the questions businesses ask after their first mis-sent credential. None of the three offers a per-secret audit timeline, dashboard revocation across a team, role-based access, and delivery notifications in one place. That's the slice LinkPilot occupies: the same atomic burn-after-read primitive, plus audit timelines, revocation, file attachments, passphrases hashed client-side, team workspaces — and branded short links with analytics in the same product. It's hosted-only, so self-host purists should stick with pwpush or PrivateBin. *Update, 29 September 2026: this sentence originally noted that LinkPilot did not claim end-to-end encryption. It now encrypts text payloads in the browser and holds no key, attachments included. [Exact model here](/security-architecture).* You can try it without an account via the [free secret link generator](/tools/free-secret-link-generator). ## The bottom line - **Personal, occasional:** OneTimeSecret. - **IT/engineering, self-hosted:** Password Pusher. - **Anonymous throwaway notes:** Privnote works, but type the domain yourself and keep the stakes low. - **Teams that need audit + revocation:** a workspace product like LinkPilot. Whichever you land on, pair it with the habits from [how to send a password securely](/secure-password-sharing): short expiry, out-of-band passphrase, rotate on anything suspicious. Q: Which is better, OneTimeSecret or Privnote? A: OneTimeSecret, for most people: it's open source (verifiable), self-hostable, and supports passphrases. Privnote is slightly faster for anonymous notes but is closed source and has a widely reported lookalike-clone phishing problem. Q: Which is better, OneTimeSecret or Password Pusher? A: They overlap heavily. Password Pusher adds view-count caps (burn after N views), deletable links, a file-push module, and a first-class API — usually the better pick for IT teams. OneTimeSecret is simpler and equally solid for one-off text secrets. Q: Do any of these tools have an audit trail or team roles? A: No — all three are single-purpose tools without per-tenant audit timelines or RBAC. If you need to prove who viewed what and revoke from a dashboard, that's the gap a workspace product like LinkPilot fills. Q: Can all three be self-hosted? A: OneTimeSecret and Password Pusher are open source and self-hostable. Privnote is closed source and hosted-only. ### Is Privnote Safe? 3 Risks Before You Paste a Password — https://uselinkpilot.com/blog/is-privnote-safe Published: 2026-07-09 · Updated: 2026-10-02 · By W. Miller Safe enough for a casual note, not for credentials. The clone-site phishing Krebs documented, unverifiable encryption, and no way to revoke - plus fixes. **Is Privnote safe? For a casual note between friends, yes. For a password, an API key or anything a business cares about, no.** The one-view mechanism works; the risks are everything around it. There are three, and the first one has cost real people real money. *Updated 2 October 2026: added what we could verify about Privnote's encryption library from its live page source, the 2024 clone network documented by Krebs on Security, and corrected an earlier statement about LinkPilot's encryption. Where this post says "we checked", the check date is 2 October 2026.* This post is the safety verdict. If you already know you want something else, the [best Privnote alternatives](/blog/best-privnote-alternatives) roundup compares seven tools on encryption, revocation, audit logs and price, and [LinkPilot vs Privnote](/compare/linkpilot-vs-privnote) is the head-to-head for our own product. ## What does Privnote do well? Credit where it is due. The core product is genuinely convenient: no account, paste a note, get a link, the note is destroyed after it is read. Privnote's own page says the note is "encrypted in your browser and then stored in Privnote", offers a "manual password" to encrypt the note, expiry windows of 1 hour, 24 hours, 7 days or 30 days, an e-mail notification when the note is destroyed, and the sensible advice to send the password by "a different method" than the link.<sup>[1]</sup> For "here's the Wi-Fi key, delete after reading" between people who trust each other, it is fine. ## What are the 3 risks? ### 1. Clone-site phishing that reads your note Privnote's brand recognition has spawned lookalike domains, and the best-documented ones were built to steal. In June 2020, Brian Krebs reported that **privnotes.com** (plural) imitated Privnote, did not actually encrypt notes, and ran a script that detected bitcoin addresses in a note and replaced them with the scammers' own, but only when the sender and the recipient opened the note from different IP addresses, so the sender checking their own note never saw the swap.<sup>[2]</sup> In April 2024 he documented a whole network of clones, including privnote[.]co, tornote[.]io, privatenote[.]io, pirvnota[.]com, privatemessage[.]net, privnode[.]com and privnate[.]com, that "function more or less as advertised but also quietly inject their own cryptocurrency payment addresses when a note is created that contains crypto wallets". Four addresses tied to one of those sites took in nearly $18,000 in four days, and the operators rotated in new addresses roughly every five days.<sup>[3]</sup> The danger is not the real site. It is that a search-result or ad click can land you on a convincing fake whose entire purpose is reading your secret. If you use Privnote, type the domain yourself. A link-reputation check like our free [link trust score](/tools/link-trust-score) tool can sanity-check a suspicious URL before you paste anything into it. ### 2. Encryption you cannot verify Privnote says notes are encrypted so the server cannot read them; in 2020 the company told Krebs that real Privnote uses encryption "so that even Privnote itself cannot read the contents".<sup>[2]</sup> That may well be true. But the code is closed source, so nobody outside the company can confirm it, and what can be seen from the outside is not reassuring. Here is exactly what we could and could not verify on 2 October 2026: - **Verified:** the live privnote.com page loads a JavaScript file named `gibberish-aes.js` from its static assets.<sup>[1]</sup> - **Verified:** the upstream Gibberish-AES project on GitHub was archived (made read-only) on 16 October 2018. Its own README says it "only supports CBC AES encryption mode", is built to be compatible with OpenSSL's MD5-based key derivation, and carries a deprecation note recommending libsodium or Stanford's JavaScript Crypto Library instead because Gibberish-AES "is quite old, and uses an older and non-authenticated cipher mode, CBC".<sup>[4]</sup> - **Not verified:** we did not reverse-engineer Privnote's minified application code to confirm that this library is the code path that encrypts a new note today, as opposed to a legacy path for old notes. Treat the finding as "the only crypto library the page ships", not as proof of what runs. Contrast that with tools whose source you can read: PrivateBin documents 256-bit AES in Galois Counter Mode (an authenticated mode) run in the browser with the key in the URL fragment,<sup>[5]</sup> and Yopass encrypts in the browser with OpenPGP under an Apache-2.0 licence.<sup>[6]</sup> For a secrecy tool, "trust us" is a materially weaker position than "check for yourself". ### 3. No way to undo a mistake Sent the note to the wrong person? There is no dashboard to revoke it. Need to prove to a client that a credential was never opened? There is no audit trail: the destruction e-mail tells you the note was read, not by whom or from where. Wondering whether it was read by the intended recipient or by an e-mail security gateway that fetched the link? You cannot tell. None of this matters for casual notes; all of it matters at work. ## What should you use instead? <table> <thead> <tr><th>Your constraint</th><th>Better fit</th><th>Why</th></tr> </thead> <tbody> <tr><td>Business hand-offs, client credentials</td><td>LinkPilot</td><td>Per-secret audit timeline, revocation, passphrases, file attachments, team workspaces; encrypted in your browser with the key in the URL fragment</td></tr> <tr><td>Mainstream, already in a password manager</td><td>Bitwarden Send</td><td>Text Sends free; file Sends on Premium; delete or disable before expiry</td></tr> <tr><td>Anonymous personal notes, open source</td><td>OneTimeSecret</td><td>MIT-licensed, self-hostable, REST API, free tier</td></tr> <tr><td>Self-hosted, IT-controlled</td><td>Password Pusher</td><td>Apache-2.0, view caps, expiring links, audit logs, API</td></tr> <tr><td>Encryption you can read the source of</td><td>PrivateBin / Yopass</td><td>Encrypted in the browser, key in the link, auditable code</td></tr> </tbody> </table> The full seven-tool comparison, with a pricing table and each vendor's pricing page cited, is in [best Privnote alternatives](/blog/best-privnote-alternatives). For our own product against Privnote feature by feature, including the honest caveat that LinkPilot is hosted-only and closed source, see [LinkPilot vs Privnote](/compare/linkpilot-vs-privnote). *Correction history: the first version of this post said LinkPilot did not claim to encrypt in the browser. Since 29 September 2026 it encrypts text payloads and attachments in the browser, with the key in the URL fragment; secrets created before that date were stored as plaintext until they expired. [Here is exactly what it claims](/security-architecture).* ## How do you use any one-time note tool safely? 1. **Type the domain yourself.** Never reach a secrets tool through ads or search results; that is the clone-site attack in one line. 2. **Add a passphrase** and send it through a different channel than the link. 3. **Set the shortest workable expiry** so unopened notes die on their own. 4. **Rotate the secret if anything looks off.** A burned-before-read status, or a destruction e-mail before the recipient opened it, is your early warning that someone else did. 5. **Never put the password itself in e-mail or chat**, only the link. Our [secure password sharing guide](/secure-password-sharing) compares the five ways teams share credentials and why that rule matters. The one-view mechanism is a genuinely good idea, which is why so many tools implement it. The safety question is everything around the mechanism: who runs it, whether you can verify it, and what you can do when something goes wrong. Judge Privnote, and every alternative, ours included, on those three questions. ## References **[1]** Privnote. *Home page and page source* (checked 2 October 2026). <https://privnote.com/> **[2]** Krebs, B. (14 June 2020). *Privnotes.com Is Phishing Bitcoin from Users of Private Messaging Service Privnote.com*. Krebs on Security. <https://krebsonsecurity.com/2020/06/privnotes-com-is-phishing-bitcoin-from-users-of-private-messaging-service-privnote-com/> **[3]** Krebs, B. (4 April 2024). *Fake Lawsuit Threat Exposes Privnote Phishing Sites*. Krebs on Security. <https://krebsonsecurity.com/2024/04/fake-lawsuit-threat-exposes-privnote-phishing-sites/> **[4]** mdp/gibberish-aes. *A fully OpenSSL compliant javascript library for AES encryption* (repository archived 16 October 2018). GitHub. <https://github.com/mdp/gibberish-aes> **[5]** PrivateBin/PrivateBin. *A minimalist, open source online pastebin where the server has zero knowledge of pasted data*. GitHub. <https://github.com/PrivateBin/PrivateBin> **[6]** jhaals/yopass. *Secure sharing of secrets, passwords and files*. GitHub. <https://github.com/jhaals/yopass> Q: Is Privnote safe to use? A: For low-stakes personal notes, generally yes: the note is destroyed after it is read and the service has run for years. For passwords, business credentials or anything valuable, three risks add up: a documented network of lookalike phishing clones, closed-source code whose encryption claims cannot be checked, and no way to revoke a note or see whether it was opened. Q: What are Privnote clone sites? A: Lookalike domains that copy Privnote's name and design. Krebs on Security documented one in 2020 (privnotes.com) that read notes and swapped bitcoin addresses, and in 2024 a network of them (privnote.co, tornote.io, privatenote.io and others) that injected the attackers' own cryptocurrency addresses into notes. Type the exact domain rather than clicking a search result or ad. Q: Does Privnote really delete notes after reading? A: Privnote states notes are destroyed after being read or after the expiry you choose (1 hour to 30 days), and the reading flow behaves that way in testing. Because the service is closed source, deletion ultimately rests on trusting the operator; nothing lets you verify it from outside. Q: Can Privnote messages be traced? A: Not by a recipient: a note link carries no sender identity. The operator sees what any web server sees (IP address, browser, time), and a note read through a clone site is read by the clone's operator. The practical risk is not tracing but interception by a fake site. Q: What should I use instead of Privnote for work? A: A tool with an audit trail and revocation (LinkPilot), an open-source project you can self-host (OneTimeSecret, Password Pusher), or a tool whose in-browser encryption you can read the source of (PrivateBin, Yopass). Our Privnote alternatives roundup compares seven on exactly those points. ### Bitly Pricing Explained: Free Limits and Paid Tiers (2026) — https://uselinkpilot.com/blog/bitly-pricing-explained Published: 2026-07-09 · By LinkPilot Team Bitly's free plan is widely reported at 10 links a month; paid plans start in the mid-$30s for Growth. What each tier gates and how the math compares. Bitly's pricing page is the most-visited in the link-management category, and also the most-asked-about — because what each tier includes has changed repeatedly. This teardown explains the structure in plain English, with the caveat that applies to every number here: **as published July 2026 — verify current details with Bitly before buying.** ## What does Bitly actually cost? **Bitly's free plan is limited to a handful of links per month (widely reported at 10) with a short analytics window. Paid plans start in the mid-$30s per month for Growth, climbing through higher tiers to custom enterprise pricing. The pattern to understand: core shortening is cheap, but branded domains, deeper analytics, and team features arrive one tier later than you expect.** ## How is Bitly's pricing structured? Bitly sells a platform (links + QR codes + landing pages), and each capability has its own ceiling per tier. In practice the tiers behave like this: <table> <thead> <tr><th>Tier</th><th>Rough positioning</th><th>What typically pushes you up</th></tr> </thead> <tbody> <tr><td>Free</td><td>Trial-grade: ~10 links/mo, short analytics history</td><td>Any real campaign volume</td></tr> <tr><td>Core (entry paid)</td><td>Light personal/creator use</td><td>Custom domain needs, link caps</td></tr> <tr><td>Growth (~$35/mo)</td><td>The tier most small teams actually need</td><td>Link caps, deeper analytics, team seats</td></tr> <tr><td>Premium / Enterprise</td><td>High volumes, SSO, integrations</td><td>Custom quote territory</td></tr> </tbody> </table> Two structural things to know before comparing: - **Link caps are per month, not total.** A "500 links" allowance is a creation budget that resets monthly; heavy campaign months eat it fast. - **Analytics history is tiered.** On lower tiers you may only see a limited window of click history — check the current terms if year-over-year reporting matters to you. Bitly has also raised prices more than once since 2023 (widely reported and discussed by users), which is why "bitly pricing" is such a heavily searched topic in the first place. ## What's the honest case for paying Bitly? Brand recognition (recipients trust bit.ly links), a genuinely strong QR code suite, mature enterprise integrations, and procurement-friendly vendor status. If those are your constraints, Bitly is a defensible choice and the Growth tier is where most teams should land. ## How does the math compare to alternatives? <table> <thead> <tr><th>Need</th><th>Bitly</th><th>LinkPilot</th><th>Dub</th></tr> </thead> <tbody> <tr><td>Free plan</td><td>~10 links/mo</td><td>50 links, 1,000 clicks/mo, 5 secret links, 7-day analytics</td><td>25 links, 1,000 clicks/mo</td></tr> <tr><td>Unlimited links + API</td><td>Higher tiers</td><td>$29/mo (Pro)</td><td>~$30/mo (Pro)</td></tr> <tr><td>Custom domain</td><td>Paid tiers</td><td>Pro ($29/mo) and up</td><td>Free plan up</td></tr> <tr><td>Secret / burn-after-read links</td><td>Not offered</td><td>Included on every plan</td><td>Not offered</td></tr> <tr><td>White-label agency workspaces</td><td>Enterprise conversation</td><td>$299/mo flat, 25 client workspaces</td><td>Not a focus</td></tr> </tbody> </table> Competitor figures as published July 2026 — verify with each vendor. The pattern: Bitly prices the *platform brand*; challengers price the *capability*. If the capability list is what you're buying, comparison shopping pays for itself in an afternoon. ## Which questions should you ask before picking a tier? 1. **How many links do you actually create per month?** Check last quarter's real number — most small teams overestimate. 2. **Do you need your own domain?** If yes, find the cheapest tier that includes it in each tool; this single feature moves the price comparison more than anything else. 3. **How long must analytics history last?** Tiered history windows are the most commonly missed fine print. 4. **Who else needs a seat?** Per-seat math quietly doubles some quotes. 5. **Do you also share credentials with clients or teammates?** If so, a tool that bundles [secret links](/secure-password-sharing) removes a second subscription entirely. For the full side-by-side, see [LinkPilot vs Bitly](/compare/linkpilot-vs-bitly), our [pricing page](/pricing) (every LinkPilot number on one table), and the broader [best Bitly alternatives](/blog/best-bitly-alternatives) roundup. And if you just need a short link right now, the [free shortener](/tools/free-link-shortener) works without an account. Q: Is Bitly free? A: Bitly has a free plan, but it is limited — widely reported at 10 links per month with a short analytics window (as published July 2026; verify on bitly.com). It's enough to try the product, not to run campaigns. Q: How much does Bitly cost per month? A: Paid plans start in the mid-$30s per month for the Growth tier as published July 2026, with higher tiers and enterprise pricing above that. Bitly has adjusted prices several times in recent years, so always check the current pricing page. Q: Is Bitly worth it? A: If your organization values the bit.ly brand, its QR tooling, and enterprise integrations, it can be. If you mainly need branded short links plus analytics, several alternatives deliver the same core capability for less — compare on the two or three features you actually use. Q: What is the cheapest Bitly alternative with a custom domain? A: Several tools include a custom domain at lower cost than Bitly's equivalent tier — LinkPilot includes them from Pro at $29/mo, and Short.io and Dub include custom domains on free/low tiers (as published July 2026; verify with each vendor). ### 7 Best Privnote Alternatives in 2026 (Free & Self-Hosted) — https://uselinkpilot.com/blog/best-privnote-alternatives Published: 2026-07-09 · Updated: 2026-10-04 · By W. Miller Clone-site phishing and closed-source crypto drive people off Privnote. 7 alternatives compared on encryption, revocation, audit logs and price. LinkPilot sends a secret link that is gone after it is opened. Whether you are searching for a one-time secret or a Privnote alternative, the flow is the same: paste the secret, send the link, and the recipient's first reveal burns it. You can make one without an account at the [free secret link generator](/tools/free-secret-link-generator). Checked 4 October 2026. ## Quick comparison: one-time secret tools (checked 4 October 2026) <table> <thead> <tr><th>Tool</th><th>Burn after open</th><th>Expiration</th><th>Account required to create</th><th>Where encryption happens</th><th>Price</th></tr> </thead> <tbody> <tr><td>LinkPilot</td><td>Yes. The recipient's reveal burns the payload; a link preview or a plain GET does not.</td><td>Yes. The no-account tool expires a secret after 7 days by default. Signed-in secrets offer 1 hour, 24 hours or 7 days on every plan; a custom expiry date is a Pro feature.</td><td>No for the <a href="/tools/free-secret-link-generator">free secret link generator</a>. The Free plan caps active secret links at 5.</td><td>In your browser: client-side AES-GCM, with the key in the URL fragment.</td><td>Free, $0, with the 5-secret-link cap. Pro $29/mo.</td></tr> <tr><td>OneTimeSecret</td><td>Yes: "Once the recipient opens the link, the data is permanently destroyed" (onetimesecret.com, checked 4 October 2026).</td><td>Basic plan "up to 14 days"; Identity Plus and Team Plus "up to 30 days" (onetimesecret.com/en/pricing, checked 4 October 2026).</td><td>Not verified. The home page shows a create form but does not say whether an account is needed (checked 4 October 2026).</td><td>Vendor statement: "Your secrets are securely encrypted on our servers" (docs.onetimesecret.com, checked 4 October 2026). In-browser encryption is not stated.</td><td>Basic €0/month; Identity Plus €35/month; Team Plus €125/month, EU pricing as displayed (onetimesecret.com/en/pricing, checked 4 October 2026).</td></tr> <tr><td>password.link</td><td>Yes: links "self-destruct after one view" (password.link, checked 4 October 2026).</td><td>Configurable per link ("expiration time"); specific limits not verified (password.link, checked 4 October 2026).</td><td>No: the home page offers "Create a one-time link" without signing in; an account unlocks attachments, branding and notifications (password.link, checked 4 October 2026).</td><td>Vendor statement: "Your secret is encrypted in this browser before it leaves," AES-256-GCM, with "the encrypted secret and the private part sent to our backend" (password.link, checked 4 October 2026).</td><td>Free account offered, "no credit card required"; paid plan prices not verified (the pricing page returned 404 on 4 October 2026).</td></tr> <tr><td>1time.io</td><td>Yes: "Links burn after reading by default" (1time.io, checked 4 October 2026).</td><td>1 hour, 1 day, 3 days, 7 days or 30 days (1time.io, checked 4 October 2026).</td><td>No: "No signup required" (1time.io, checked 4 October 2026).</td><td>Vendor statement: "AES encryption happens in your browser. The server only stores ciphertext," with the key in the URL fragment (1time.io, checked 4 October 2026).</td><td>"Free and open source" per the vendor (1time.io, checked 4 October 2026).</td></tr> </tbody> </table> Vendor cells quote each vendor's own public page on the date shown; we did not test their code. The LinkPilot row is taken from our own pricing configuration and client code. Privnote made one-view notes mainstream: paste, share, gone. For a quick anonymous note it still works. But it is closed source, it offers nothing for teams, and its popularity has made it a target: Krebs on Security has documented lookalike clone sites that read notes and swap the cryptocurrency addresses inside them, in 2020 and again in 2024.<sup>[1]</sup><sup>[2]</sup> That is a real problem for a tool whose whole job is receiving secrets. The full safety verdict is in [is Privnote safe?](/blog/is-privnote-safe); this post is the alternatives list. *Updated 2 October 2026: added Bitwarden Send and scrt.link (seven alternatives, up from five), a security table and a pricing table with every vendor's pricing page cited, a section on why Privnote's encryption cannot be verified based on its live page source, and outbound references throughout. Every price and limit below was checked on 2 October 2026; vendors change them, so re-check before you buy.* ## What is the best Privnote alternative? LinkPilot sends a secret link that is gone after it is opened. **For business use, LinkPilot is the strongest Privnote alternative: it adds revocation, a per-secret audit timeline, passphrases, file attachments and team workspaces to the same burn-after-read flow, and encrypts in your browser with the key in the URL fragment. If your team already runs Bitwarden, Bitwarden Send is the lowest-friction swap. For anonymous notes, OneTimeSecret is the trustworthy open-source default, and PrivateBin or Yopass give you encryption whose source you can read if you self-host.** ## How we evaluated Six criteria, applied to each tool on 2 October 2026 from its public site, pricing page and source repository where one exists: whether the code is open source and self-hostable; whether the encryption claim can be verified from published source; whether a sender can revoke an unread note; whether there is an audit trail; what the free tier actually limits; and what the paid tiers cost. We did not run every tool under a debugger. Where a vendor does not publish a fact, the table says "Not published" rather than guessing. LinkPilot is our own product, so its row is a claim by the publisher; the [security architecture](/security-architecture) page is the thing to hold us to. ## Security and verification, compared <table> <thead> <tr><th>Tool</th><th>Open source</th><th>Self-host</th><th>Encryption verifiable?</th><th>Revoke before view</th><th>Audit trail</th><th>Price</th></tr> </thead> <tbody> <tr><td>LinkPilot</td><td>No (hosted)</td><td>No</td><td>Partly: model documented (AES-GCM-256 in browser, key in URL fragment), source not public</td><td>Yes (account)</td><td>Yes, per secret (Pro)</td><td>Free; Pro $29/mo</td></tr> <tr><td>Bitwarden Send</td><td>Yes (server AGPL-3.0)<sup>[3]</sup></td><td>Yes<sup>[4]</sup></td><td>Yes: encrypted on creation, source published</td><td>Yes (disable or delete)<sup>[5]</sup></td><td>Event logs on business plans</td><td>Text free; files on Premium $19.80/yr</td></tr> <tr><td>OneTimeSecret</td><td>Yes (MIT)<sup>[6]</sup></td><td>Yes (Docker)</td><td>Source is public; its docs do not describe in-browser encryption</td><td>Yes (burn via API v2)<sup>[7]</sup></td><td>Minimal</td><td>Free; Identity Plus €35/mo</td></tr> <tr><td>Password Pusher</td><td>Yes (Apache-2.0)<sup>[8]</sup></td><td>Yes (Docker)</td><td>Source is public; encrypted at rest on the server (AES-256-GCM)<sup>[9]</sup></td><td>Yes (expire by views or time, deletable)</td><td>Yes (audit logs on Free)</td><td>Free; Solo $19/mo</td></tr> <tr><td>PrivateBin</td><td>Yes (zlib/libpng)<sup>[10]</sup></td><td>Yes (self-host only, or a public instance)</td><td>Yes: AES-256-GCM in browser, key in URL fragment, source public<sup>[10]</sup></td><td>Delete link only</td><td>No</td><td>Free</td></tr> <tr><td>Yopass</td><td>Yes (Apache-2.0)<sup>[11]</sup></td><td>Yes (Docker, Kubernetes)</td><td>Yes: OpenPGP in browser, source public<sup>[11]</sup></td><td>Not published</td><td>No</td><td>Free; files over 1 MB need an enterprise licence</td></tr> <tr><td>scrt.link</td><td>Claimed; repository not located on 2 Oct 2026<sup>[12]</sup></td><td>White-label hosted offering</td><td>Claimed: key in the link, never sent to the server; not verified by us</td><td>Not published</td><td>Read receipts on paid tiers</td><td>Free; Secret $1/mo billed yearly</td></tr> <tr><td>Privnote (baseline)</td><td>No</td><td>No</td><td>No: closed source; page ships an AES-CBC library archived in 2018<sup>[13]</sup><sup>[14]</sup></td><td>No</td><td>No (destruction e-mail only)</td><td>Free</td></tr> </tbody> </table> Checked 2 October 2026 from each project's site and repository. "Encryption verifiable" means a third party can read the code that runs in the browser; it does not mean we audited it. ## Pricing, compared <table> <thead> <tr><th>Tool</th><th>Free tier and its limits</th><th>Paid from</th><th>What paid adds</th><th>Source</th></tr> </thead> <tbody> <tr><td>LinkPilot</td><td>5 active secret links, burn-after-read, default expiry; no signup for the free tool</td><td>$29/mo (Pro)</td><td>50 secret links, passphrase protection, custom expiry and the audit timeline, 5 custom domains; Agency $299/mo</td><td><a href="/pricing">uselinkpilot.com/pricing</a></td></tr> <tr><td>Bitwarden Send</td><td>Text Sends up to 1,000 characters, 31-day maximum life, optional password and access count</td><td>$19.80/yr (Premium, $1.65/mo billed annually)</td><td>File Sends (500 MB desktop, 100 MB mobile); Families $47.88/yr; Teams $4 and Enterprise $6 per user per month</td><td><a href="https://bitwarden.com/pricing/" rel="noopener">bitwarden.com/pricing</a>, <a href="https://bitwarden.com/help/about-send/" rel="noopener">About Send</a></td></tr> <tr><td>OneTimeSecret</td><td>Basic €0: one custom domain, expiry up to 14 days, e-mail delivery, REST API</td><td>€35/mo (Identity Plus)</td><td>Unlimited domains, branding, expiry up to 30 days, unlimited members; Team Plus €125/mo adds RBAC and SSO</td><td><a href="https://onetimesecret.com/en/pricing" rel="noopener">onetimesecret.com/pricing</a></td></tr> <tr><td>Password Pusher</td><td>$0: expiring links by views or time, passphrase, audit logs, JSON API and CLI, no account needed</td><td>$19/mo (Solo)</td><td>File uploads, branding, custom domain; Team $29/mo (3 users, RBAC, webhooks); Organization $49/mo (5 users, SSO); self-hosted plans priced separately</td><td><a href="https://eu.pwpush.com/pricing" rel="noopener">pwpush.com/pricing</a></td></tr> <tr><td>PrivateBin</td><td>Free software; you run the instance (file upload off by default, size limit configurable)</td><td>n/a</td><td>n/a</td><td><a href="https://github.com/PrivateBin/PrivateBin" rel="noopener">github.com/PrivateBin/PrivateBin</a></td></tr> <tr><td>Yopass</td><td>Free software; expiry 1 hour, 1 day or 1 week; hosted demo at share.yopass.se</td><td>Enterprise licence (price not published)</td><td>File uploads larger than 1 MB</td><td><a href="https://yopass.se/" rel="noopener">yopass.se</a>, <a href="https://github.com/jhaals/yopass" rel="noopener">github.com/jhaals/yopass</a></td></tr> <tr><td>scrt.link</td><td>Confidential $0: text, files to 10 MB, 24-hour retention</td><td>$1/mo billed yearly ($1.50 monthly)</td><td>Secret: 1 GB files, 7-day retention, password, read receipts; Top Secret $5/mo yearly ($7.50 monthly): 100 GB files, 30 days, API</td><td><a href="https://scrt.link/pricing" rel="noopener">scrt.link/pricing</a></td></tr> <tr><td>Privnote</td><td>Free: text notes, optional password, expiry 1 hour to 30 days, destruction e-mail</td><td>n/a</td><td>n/a</td><td><a href="https://privnote.com/" rel="noopener">privnote.com</a></td></tr> </tbody> </table> All prices checked 2 October 2026 on the pages linked in the Source column. Annual prices are shown as the vendor states them. ## Why Privnote's encryption cannot be verified Privnote's page says a note is "encrypted in your browser and then stored in Privnote", and in 2020 the company told Krebs on Security that it encrypts notes "so that even Privnote itself cannot read the contents".<sup>[1]</sup><sup>[13]</sup> The claim may be true. The problem is that nobody outside the company can check it, and what is visible from outside does not help. What we verified on 2 October 2026: the live privnote.com page loads a script named `gibberish-aes.js` from its static assets.<sup>[13]</sup> The upstream Gibberish-AES project on GitHub was archived, read-only, on 16 October 2018. Its README states that it "only supports CBC AES encryption mode", that it is built to be OpenSSL-compatible (the README's own example derives the key with `-md md5`), and it carries a deprecation note recommending libsodium or Stanford's JavaScript Crypto Library because the library "uses an older and non-authenticated cipher mode, CBC".<sup>[14]</sup> What we did not verify: whether that library is the code path that encrypts a new note today, or a legacy path kept for old notes. We did not reverse-engineer the minified application code. So the honest statement is: the only cryptography library Privnote's page ships is one its own author deprecated in 2018 for using an unauthenticated mode, and Privnote publishes nothing that would let you confirm what it actually does with it. Compare PrivateBin, which documents "256bit AES in Galois Counter mode", encrypted and decrypted in the browser with the key in the URL fragment, in a public repository,<sup>[10]</sup> or Yopass, which encrypts in the browser with OpenPGP under Apache-2.0.<sup>[11]</sup> You can disagree with their choices; you can at least read them. ## 1. LinkPilot: for anyone sharing on behalf of a business Privnote's gaps are exactly what businesses need: proof a credential was (or was not) viewed, the ability to kill an unread note, and a record of who shared what. LinkPilot's secret links burn atomically on first reveal, log every lifecycle event (created, viewed, failed passphrase, burned, expired, revoked) to a per-secret timeline, support revocation from the dashboard, and take file attachments behind the same passphrase and expiry controls. Slack and e-mail link previews cannot trigger the burn; a `GET` returns metadata only and a view is recorded on an explicit reveal. Since 29 September 2026 the payload is encrypted in the browser with AES-GCM-256 and the key travels in the URL fragment, which browsers never send to a server. Two trade-offs stated plainly: LinkPilot is hosted-only and closed source, so self-hosters should look elsewhere, and secrets created before 29 September 2026 were stored as plaintext until they expired. The Free plan caps active secret links at 5; passphrases, custom expiry and the audit timeline are on Pro at $29/month. Try the [burn-after-read tool](/tools/burn-after-read-secret) without an account, read [LinkPilot vs Privnote](/compare/linkpilot-vs-privnote) for the head-to-head, or see the [security architecture](/security-architecture). ## 2. Bitwarden Send: the mainstream choice if you already use Bitwarden Bitwarden Send "is a tool to transmit sensitive text or files directly to anyone through secure, temporary links". Text Sends are free (up to 1,000 characters); file Sends need Premium, with a 500 MB limit on desktop and 100 MB on mobile. A Send lives at most 31 days, can carry a password and a maximum access count, and can be disabled or deleted before it expires.<sup>[5]</sup> The server is open source under AGPL-3.0 with Bitwarden's additional licences,<sup>[3]</sup> and Bitwarden documents self-hosting on your own Linux server.<sup>[4]</sup> What it lacks is a per-secret audit trail for individuals: event logs are a business-plan feature. If your organisation is already in Bitwarden, this is the lowest-friction Privnote replacement on the list. ## 3. OneTimeSecret: the trustworthy anonymous default Open source under MIT, long-lived, and simple.<sup>[6]</sup> If all you want is Privnote without the clone-site anxiety, OneTimeSecret is the closest like-for-like swap: a single-use link, optional passphrase, and self-hosting with one `docker run`. Its Basic plan is free and includes a custom domain, expiry up to 14 days and the REST API; Identity Plus is €35/month.<sup>[15]</sup> API v2 added burn operations, so a sender can destroy an unread secret.<sup>[7]</sup> It remains single-purpose, with no teams and no real audit trail, and its documentation does not describe encrypting in the browser. See [best OneTimeSecret alternatives](/blog/best-onetimesecret-alternatives) for that tool's own trade-offs. ## 4. Password Pusher: the IT department's pick Apache-2.0 licensed with a Docker Compose deployment.<sup>[8]</sup> Pushes expire by views and/or time and the data is removed once expired; there is a JSON API (v2) and a CLI. The Free plan on the hosted service includes passphrase protection, audit logs and the API with no account; Solo at $19/month adds file uploads, branding and a custom domain; Team ($29) and Organization ($49) add RBAC, webhooks and SSO; self-hosted plans are priced separately.<sup>[9]</sup> Encryption is server-side at rest (the pricing page lists AES-256-GCM plus TLS), so the operator of the instance is in the trust boundary, which is fine when the operator is you. Comparison at [LinkPilot vs Password Pusher](/compare/linkpilot-vs-password-pusher). ## 5. PrivateBin: the strongest verifiable encryption model PrivateBin encrypts and decrypts in the browser with 256-bit AES in Galois Counter Mode; the key is part of the URL after the `#`, so the server stores only ciphertext. It offers burn after reading, a password option, and file uploads (off by default, size limit adjustable), under the zlib/libpng licence.<sup>[10]</sup> If your threat model includes "the operator reads my notes", PrivateBin answers it in a way no server-side tool can. The cost is operating an instance (or trusting someone else's) and living without workflow features: no accounts, no audit trail, revocation only via the delete link. See [LinkPilot vs PrivateBin](/compare/linkpilot-vs-privatebin). ## 6. Yopass: in-browser encryption without running much Apache-2.0, encrypts in the browser with OpenPGP, and easy to self-host with Docker and a Memcached or Redis backend; a hosted demo runs at share.yopass.se. Expiry options are 1 hour, 1 day or 1 week, and one-time links are removed after first retrieval. File uploads are supported, with files larger than 1 MB reserved for the enterprise licence.<sup>[11]</sup> A good pick for developers who want in-browser encryption with less setup than PrivateBin. No revoke and no audit trail. ## 7. scrt.link: hosted, with big files on paid tiers scrt.link states that the encryption key "is never stored; instead, it becomes part of the link itself" and is never transmitted to the server, and that its code is on GitHub; we could not locate the repository on 2 October 2026, so treat both as the vendor's claims.<sup>[12]</sup> The free Confidential tier gives text, files up to 10 MB and 24-hour retention with unlimited secrets; Secret is $1/month billed yearly for 1 GB files, 7-day retention, a password option and read receipts; Top Secret is $5/month billed yearly for 100 GB files, 30-day retention and API access.<sup>[16]</sup> It is the right pick if the thing you are sending is large. No per-secret audit trail beyond read receipts, and no published revocation. ## Self-hosted and open-source options at a glance - **OneTimeSecret**: `docker run -p 3000:3000 ... onetimesecret/onetimesecret` with a Redis URL.<sup>[6]</sup> - **Password Pusher**: Docker Compose with a `TLS_DOMAIN` for automatic Let's Encrypt.<sup>[8]</sup> - **PrivateBin**: a PHP application you drop on any web host; no database required by default.<sup>[10]</sup> - **Yopass**: Docker Compose or Kubernetes, Memcached or Redis.<sup>[11]</sup> - **Bitwarden**: full self-hosted deployment documented for Linux.<sup>[4]</sup> LinkPilot, scrt.link and Privnote are hosted only. ## How to spot a Privnote clone site From the two Krebs investigations:<sup>[1]</sup><sup>[2]</sup> 1. **The domain is almost right.** privnotes.com (plural), privnote.co, privnode.com, privnate.com, pirvnota.com: every documented clone is a typo or TLD swap of the real name. 2. **You arrived from a search result or an ad.** The clone operators buy the traffic. Type the domain. 3. **A cryptocurrency address in your note changed.** The 2020 clone swapped addresses only when sender and recipient used different IP addresses, so checking your own note proved nothing. 4. **The site is not the one your contact used last time.** A link-reputation check like our free [link trust score](/tools/link-trust-score) can flag a young or suspicious domain before you paste. ## Which one should you pick? - **Client hand-offs, MSPs, onboarding:** LinkPilot. The audit trail and revocation are the whole point. - **Already in Bitwarden:** Bitwarden Send. - **Personal anonymous notes:** OneTimeSecret. - **Self-host everything:** Password Pusher for workflow, PrivateBin or Yopass for encryption you can read. - **Large files:** scrt.link. Whichever you choose, send the passphrase through a different channel than the link; it is the habit that does the most work per second of effort. Our [secure password sharing guide](/secure-password-sharing) covers that rule and the four others worth adopting. ## What changed in this update - **4 October 2026:** rewrote the opening so the one-time-secret answer and the no-account tool come first; added a dated quick-comparison table (LinkPilot, OneTimeSecret, password.link, 1time.io) and a closing call to action. Vendor sections below are unchanged. - **2 October 2026:** Bitwarden Send and scrt.link added; security and pricing tables added with sources; "Why Privnote's encryption cannot be verified" added from the live page source and the archived library's own README; references added; "self-hosted options" and "how to spot a clone" sections added. - **29 September 2026:** corrected the LinkPilot entry, which had said LinkPilot did not claim to encrypt in the browser. It now does, for text payloads and attachments, with the key in the URL fragment. ## References **[1]** Krebs, B. (14 June 2020). *Privnotes.com Is Phishing Bitcoin from Users of Private Messaging Service Privnote.com*. Krebs on Security. <https://krebsonsecurity.com/2020/06/privnotes-com-is-phishing-bitcoin-from-users-of-private-messaging-service-privnote-com/> **[2]** Krebs, B. (4 April 2024). *Fake Lawsuit Threat Exposes Privnote Phishing Sites*. Krebs on Security. <https://krebsonsecurity.com/2024/04/fake-lawsuit-threat-exposes-privnote-phishing-sites/> **[3]** bitwarden/server. *The core infrastructure backend (API, database, Docker, etc)*. GitHub. <https://github.com/bitwarden/server> **[4]** Bitwarden. *Linux Standard Deployment* (self-hosting guide). <https://bitwarden.com/help/install-on-premise-linux/> **[5]** Bitwarden. *About Send*. <https://bitwarden.com/help/about-send/> **[6]** onetimesecret/onetimesecret. *Keep sensitive info out of your email and chat logs*. GitHub. <https://github.com/onetimesecret/onetimesecret> **[7]** Onetime Secret. *REST API documentation* (API v2: metadata and burn operations). <https://docs.onetimesecret.com/en/rest-api/> **[8]** pglombardo/PasswordPusher. *Securely share sensitive information with automatic expiration & deletion*. GitHub. <https://github.com/pglombardo/PasswordPusher> **[9]** Password Pusher. *Pricing*. <https://eu.pwpush.com/pricing> **[10]** PrivateBin/PrivateBin. *A minimalist, open source online pastebin where the server has zero knowledge of pasted data*. GitHub. <https://github.com/PrivateBin/PrivateBin> **[11]** jhaals/yopass. *Secure sharing of secrets, passwords and files*. GitHub. <https://github.com/jhaals/yopass>; Yopass. *Home*. <https://yopass.se/> **[12]** scrt.link. *Home*. <https://scrt.link/> **[13]** Privnote. *Home page and page source* (checked 2 October 2026). <https://privnote.com/> **[14]** mdp/gibberish-aes. *A fully OpenSSL compliant javascript library for AES encryption* (repository archived 16 October 2018). GitHub. <https://github.com/mdp/gibberish-aes> **[15]** Onetime Secret. *Pricing*. <https://onetimesecret.com/en/pricing> **[16]** scrt.link. *Pricing*. <https://scrt.link/pricing> ## Make a one-time secret now LinkPilot sends a secret link that is gone after it is opened. Paste the secret, send the link, and the first reveal burns it. <p><a class="inline-flex items-center justify-center rounded-md bg-primary px-5 py-2.5 text-sm font-medium !text-primary-foreground no-underline hover:bg-primary/90" href="/tools/free-secret-link-generator">Create a free secret link, no account needed</a></p> Need revocation, the audit timeline or team workspaces? [Sign up for a free account](/signup). Q: What are good alternatives to Privnote? A: LinkPilot (hosted, audit trail and revocation), Bitwarden Send (free text Sends inside a mainstream password manager), OneTimeSecret and Password Pusher (open source, self-hostable, with APIs), PrivateBin and Yopass (encrypted in the browser with readable source), and scrt.link (hosted, large files on paid tiers). Which is best depends on whether you need proof of delivery, self-hosting, or verifiable encryption. Q: Is Privnote safe to use? A: For casual notes, generally yes. For passwords and business credentials the risks add up: a documented network of lookalike phishing clones, closed-source code whose encryption claims cannot be checked (the live page ships an AES library archived in 2018), and no revocation or audit trail. Our separate post, Is Privnote safe?, gives the full verdict. Q: Which encrypted note app is the best? A: If verifiable encryption is the priority, PrivateBin (AES-256-GCM in the browser, key in the URL fragment, source on GitHub) is the reference point, with Yopass close behind. If you need to prove a note was or was not opened, LinkPilot's per-secret timeline and revocation matter more than the cipher. Bitwarden Send is the best fit if your team already uses Bitwarden. Q: What is the best free Privnote alternative? A: For anonymous one-off notes, LinkPilot's free secret link tool (no signup; the Free plan caps active secret links at 5), OneTimeSecret's Basic plan and Password Pusher's Free plan all cost nothing. For self-hosters, PrivateBin and Yopass are free and open source. Bitwarden Send text Sends are free; file Sends need Premium. Q: Can Privnote messages be traced? A: Not by a recipient; a note link carries no sender identity. The operator sees what any web server sees (IP address, browser, time), and a note opened through a clone site is read by the clone's operator. The practical risk is interception by a fake site, not tracing. Q: Is there a Privnote alternative with an audit trail? A: Yes. LinkPilot records a per-secret event timeline (created, viewed, failed passphrase, burned, expired, revoked) with hashed IPs and lets you revoke unread secrets from a dashboard. Password Pusher lists audit logs on its free plan. The anonymous note tools (Privnote, PrivateBin, Yopass) do not offer one. ### OneTimeSecret Alternatives: Hosted and Self-Hosted (2026) — https://uselinkpilot.com/blog/best-onetimesecret-alternatives Published: 2026-07-09 · Updated: 2026-10-04 · By W. Miller Six OneTimeSecret alternatives compared: LinkPilot for audit trails and revocation, Password Pusher and PrivateBin for self-hosting, Yopass for E2EE. The checkable difference, as of 4 October 2026: OneTimeSecret's documentation says "Your secrets are securely encrypted on our servers" and does not state in-browser encryption. LinkPilot encrypts the secret in your browser with AES-GCM-256, keeps the key in the URL fragment, stores only ciphertext, and burns the stored secret on the first reveal. You can try that without an account at the [free secret link generator](/tools/free-secret-link-generator). OneTimeSecret has been the default answer to "how do I send this password?" for over a decade: paste a secret, get a link, the link works once. It's open source, simple, and trustworthy. But it's also deliberately minimal — and if you've landed here, you've probably hit one of its walls: no real team workspace, no per-secret audit trail, no dashboard revocation, minimal file support on the hosted tier. ## What is the best OneTimeSecret alternative? **There is no single winner — it depends on your constraint. Teams that need audit trails, revocation, and file attachments in a hosted product should look at LinkPilot. If self-hosting is mandatory, Password Pusher and PrivateBin lead the open-source field. If zero-knowledge encryption is the requirement, PrivateBin or Yopass encrypt in the browser before anything reaches a server.** ## How do the alternatives compare? <table> <thead> <tr><th>Tool</th><th>Hosting</th><th>Burn-after-read</th><th>Audit trail</th><th>Teams / RBAC</th><th>Files</th><th>Encryption model</th></tr> </thead> <tbody> <tr><td>LinkPilot</td><td>Hosted SaaS</td><td>Yes — atomic</td><td>Per-secret timeline (Pro)</td><td>Yes, 5 roles</td><td>Yes</td><td>AES-GCM-256 in the browser; key in the URL fragment (since 29 Sept 2026)</td></tr> <tr><td>Password Pusher</td><td>Hosted + self-host (open source)</td><td>View-count caps</td><td>Limited</td><td>Limited</td><td>Yes (file push)</td><td>Server-side encryption</td></tr> <tr><td>PrivateBin</td><td>Self-host (open source)</td><td>Yes</td><td>No</td><td>No</td><td>Instance-dependent</td><td>Client-side E2EE</td></tr> <tr><td>Yopass</td><td>Hosted + self-host (open source)</td><td>Yes</td><td>No</td><td>No</td><td>Limited</td><td>Client-side E2EE</td></tr> <tr><td>Cryptgeon</td><td>Self-host (open source)</td><td>Yes</td><td>No</td><td>No</td><td>Yes</td><td>Client-side encryption</td></tr> <tr><td>Privnote</td><td>Hosted</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>Claims E2EE; closed source</td></tr> <tr><td>OneTimeSecret</td><td>Hosted + self-host (open source)</td><td>Yes</td><td>Minimal</td><td>Not the focus</td><td>Limited / paid</td><td>Server-side encryption</td></tr> </tbody> </table> Details as published July 2026 — features shift; verify with each project before committing. ## 1. LinkPilot — best for teams that need accountability LinkPilot covers the same burn-after-read primitive and adds the organizational layer OneTimeSecret doesn't attempt: a per-secret audit timeline (created, viewed, burned, revoked), revocation from a dashboard, team workspaces with five roles, file attachments behind the same passphrase/expiry controls, and — unusually — branded short links with privacy-first analytics in the same workspace. The reveal is atomic (row-locked), previews from Slack/email scanners can't burn a secret, and passphrases are SHA-256 hashed in the browser. Honesty requires the flip side: LinkPilot can't be self-hosted, and its encryption client is closed source, so you can't audit it the way you can PrivateBin's or Yopass's. *Update, 29 September 2026: this paragraph originally said LinkPilot was not end-to-end encrypted. It now is, for text payloads — AES-GCM-256 in the browser with the key in the URL fragment, and attached files along with them. The self-hosting and open-source points above still stand. The [security architecture page](/security-architecture) has the current model.* Free plan includes 5 secret links; the anonymous [secret link generator](/tools/free-secret-link-generator) needs no account at all. Full head-to-head: [LinkPilot vs OneTimeSecret](/compare/linkpilot-vs-onetimesecret). ## 2. Password Pusher — best open-source all-rounder Password Pusher (pwpush) has been an IT-team staple for years: expiring URLs with view-count caps, deletable links, a file-push module, an API, and a well-maintained self-host path. If you want a single-purpose tool your infra team controls end to end, it's the strongest choice. What it lacks is a tenant model — no real RBAC or per-tenant audit reporting. Comparison: [LinkPilot vs Password Pusher](/compare/linkpilot-vs-password-pusher). ## 3. PrivateBin — best for zero-knowledge encryption PrivateBin encrypts in the browser; the server stores ciphertext and the key travels in the URL fragment. That's a genuinely stronger confidentiality model than any server-side tool on this list — if you can self-host and only need pastebin-style sharing. No dashboard, no audit trail, no teams. Comparison: [LinkPilot vs PrivateBin](/compare/linkpilot-vs-privatebin). ## 4. Yopass — E2EE with the least friction Yopass (open source, by Frejun/Johan Haals) offers client-side encryption with a clean hosted demo and easy self-hosting. A great middle ground if PrivateBin feels heavy but you still want zero-knowledge properties. Single-purpose by design. ## 5. Cryptgeon — modern self-hosted notes and files A newer Rust/Vue project supporting encrypted notes and files with view- or time-based expiry. Lightweight to run via Docker. Choose it if you like the stack and self-host anyway; it's a smaller community than pwpush or PrivateBin. ## 6. Privnote — quick, but think twice Privnote is the fastest anonymous option and fine for casual notes, but it's closed source, ad-supported, and lookalike phishing clones imitating it have been widely reported in scams. We've written a fuller assessment in [is Privnote safe?](/blog/is-privnote-safe) and a dedicated [alternatives roundup](/blog/best-privnote-alternatives). ## Which should you actually pick? - **A business or MSP handing credentials to clients:** LinkPilot — audit trail, revocation, and files are the job here, and the secret is encrypted in your browser rather than on the server. - **Self-hosting is non-negotiable:** Password Pusher (workflow features) or PrivateBin/Yopass (zero-knowledge encryption). - **Occasional personal use:** OneTimeSecret's hosted tier remains perfectly good — that's an honest answer from a competitor. Whatever you pick, adopt the same habits: short expiry, passphrase delivered out-of-band, and rotate any credential whose link was opened by the wrong party. More on that in [how to send a password securely](/secure-password-sharing). Passphrases, custom expiry and the audit timeline are on Pro at $29/mo. Try the mechanism before you compare further: the [free secret link generator](/tools/free-secret-link-generator) needs no account. Q: What is the best OneTimeSecret alternative? A: It depends on your constraint. For teams that want audit trails, revocation, and a hosted product, LinkPilot is the strongest fit. If self-hosting is a hard requirement, Password Pusher and PrivateBin are excellent open-source options. For zero-knowledge encryption specifically, PrivateBin or Yopass. Q: Is OneTimeSecret free? A: OneTimeSecret has a free hosted tier with limits and paid plans for more capacity; the software is also open source, so you can self-host it at your own infrastructure cost. Verify current plan details on onetimesecret.com. Q: Do any OneTimeSecret alternatives include an audit trail? A: Most single-purpose tools don't. LinkPilot records a per-secret timeline (created, viewed, burned, revoked) and offers dashboard revocation, which is the main functional gap teams hit with OneTimeSecret, Privnote, and similar tools. Q: Can I self-host LinkPilot? A: No — LinkPilot is a hosted SaaS. If self-hosting is a hard requirement, Password Pusher, PrivateBin, Yopass, or OneTimeSecret's open-source edition are better fits. ### Bitly Alternatives: Free Plans and Custom Domains (2026) — https://uselinkpilot.com/blog/best-bitly-alternatives Published: 2026-07-09 · By LinkPilot Team Six Bitly alternatives compared on free plans, custom domains, and pricing: LinkPilot, Dub, Short.io, Rebrandly, T.LY, and TinyURL, with honest trade-offs. Bitly is still the household name in link shortening — and for many teams, still a fine product. But its free plan has shrunk while paid prices climbed (both widely reported; verify current plans with Bitly), and that combination sends a steady stream of people searching for alternatives. Here are the ones actually worth considering, including where each beats the others. ## What is the best Bitly alternative? **For most teams, the best Bitly alternative is whichever tool gives you a custom domain and real analytics at your price point: LinkPilot if you also want secret links (custom domains start on Pro), Dub if you want a developer-first open-source platform, Short.io if you want the most generous free tier, and Rebrandly if branded domains at volume are the whole job.** ## How do the alternatives compare? <table> <thead> <tr><th>Tool</th><th>Free plan</th><th>First paid tier</th><th>Custom domain on free/low tier</th><th>Stand-out</th></tr> </thead> <tbody> <tr><td>LinkPilot</td><td>50 links, 1,000 clicks/mo, 5 secret links</td><td>$29/mo — unlimited links, 50k clicks, API</td><td>Yes — 1 on free</td><td>Secret links + analytics in one workspace</td></tr> <tr><td>Dub</td><td>25 links, 1,000 clicks/mo</td><td>~$30/mo — 50k clicks</td><td>Yes</td><td>Open source, developer DX</td></tr> <tr><td>Short.io</td><td>Generous link allowance, multiple domains</td><td>Low-cost paid tiers</td><td>Yes</td><td>Most generous free tier</td></tr> <tr><td>Rebrandly</td><td>10 links/mo (post-2025 repricing)</td><td>Metered branded links/clicks</td><td>Paid</td><td>Domain catalogue & branding focus</td></tr> <tr><td>T.LY</td><td>Basic free shortening</td><td>Low-cost</td><td>Paid</td><td>Simple, popular with solo users</td></tr> <tr><td>TinyURL</td><td>Unlimited basic redirects</td><td>Paid adds analytics/branding</td><td>Paid</td><td>Zero-friction one-off links</td></tr> <tr><td>Bitly (baseline)</td><td>10 links/mo, short analytics history</td><td>Growth from ~$35/mo</td><td>Paid</td><td>Brand recognition, QR suite</td></tr> </tbody> </table> All plan details as published July 2026 — shortener pricing changes often; verify with each vendor before deciding. ## 1. LinkPilot — best if you want more than shortening LinkPilot's free plan includes what Bitly charges for: 50 branded short links, 1,000 tracked clicks a month, real-time analytics, and a custom domain. Paid is one flat $29/mo Pro tier (unlimited links, 50,000 clicks, API) instead of a feature ladder. The differentiator is the second workflow: burn-after-read secret links for passwords and API keys, with audit timelines — no other shortener in this list does that. There's also an [anonymous shortener](/tools/free-link-shortener) that needs no account. Weaknesses, honestly: no open-source edition, and the brand is younger than everything else here. Full comparison: [LinkPilot vs Bitly](/compare/linkpilot-vs-bitly), and see [pricing](/pricing) for the plan matrix. ## 2. Dub — best for developers Dub is the open-source darling of this category: clean API, typed SDKs, great docs, modern dashboard. If your links are created by code more than by humans, start here. Its free tier is genuinely usable (25 links) and paid scales by clicks. It doesn't do secret sharing or white-label agency workspaces. Comparison: [LinkPilot vs Dub](/compare/linkpilot-vs-dub). ## 3. Short.io — best free tier Short.io's free tier (multiple custom domains and a large link allowance, as published July 2026) is the most generous in the category, which is why it appears in every roundup. The trade-off is that advanced routing and team features climb the paid tiers, and there's no ephemeral/secret capability. Comparison: [LinkPilot vs Short.io](/compare/linkpilot-vs-short-io). ## 4. Rebrandly — best for branded domains at volume Rebrandly practically invented "branded links" as a category and its domain tooling is deep. Its March 2025 repricing (free plan down to 10 links/month, widely discussed) pushed a lot of light users elsewhere — but for enterprises managing many branded domains, it remains a serious option. Comparison: [LinkPilot vs Rebrandly](/compare/linkpilot-vs-rebrandly). ## 5. T.LY and TinyURL — best for simple personal use Both do frictionless shortening with paid tiers for analytics and branding. If you need a short URL occasionally and don't measure anything, they're fine — see [LinkPilot vs TinyURL](/compare/linkpilot-vs-tinyurl) and [LinkPilot vs T.ly](/compare/linkpilot-vs-tly) for where the ceilings are. ## How do you actually switch? 1. Export your links from Bitly (CSV export in the dashboard). 2. Set up your own custom domain in the new tool — this is the step that makes you migration-proof forever. 3. Recreate the slugs that still matter via CSV import. 4. Update the links you control (bio pages, email templates, ads). Old bit.ly URLs keep redirecting on Bitly's side — you can't transfer them, which is precisely the argument for owning your short domain from now on. For the price side of the decision, see our [Bitly pricing teardown](/blog/bitly-pricing-explained). Q: What is the best free Bitly alternative? A: For a free plan with real analytics, LinkPilot (50 links, 1,000 clicks/mo, 5 secret links; custom domains start on Pro at $29/mo) and Short.io (a famously generous free tier with custom domains) lead. Dub's free tier (25 links) suits developers. All figures as published July 2026 — verify with each vendor. Q: Why are people leaving Bitly? A: The most cited reasons are free-plan cuts (widely reported at 10 links/month with short analytics history) and price increases on paid tiers, while several features remain enterprise-gated. Verify current Bitly plans on bitly.com. Q: Can I move my existing Bitly links to another shortener? A: Existing bit.ly links stay on Bitly's domain and can't be transferred. What you can migrate is your workflow: export your links to CSV, recreate the slugs on your own custom domain in the new tool, and use your domain going forward so this never happens again. Q: Which Bitly alternative also handles secret sharing? A: LinkPilot is the only tool in this roundup that pairs branded short links and analytics with burn-after-read secret links (passwords, API keys) in the same workspace. ### Why URLs Leak Sensitive Information (and How to Fix It) — https://uselinkpilot.com/blog/why-urls-leak-sensitive-information Published: 2026-05-26 · Updated: 2026-07-14 · By W. Miller Browser history, server logs, CDNs, and Referer headers keep full URLs, even over HTTPS. Where links leak and how to design URLs that are safe to leak. A URL feels private because only the people you send it to should have it. In practice, a URL is one of the most-logged pieces of data on the web: it is written down, copied, and forwarded by systems that never asked your permission and that you cannot audit. Here's exactly where it leaks, and how to design links that survive it. ## The leakage surface - **Browser history.** Every URL the user visits is stored locally and can sync to other devices — and to the browser vendor's sync service. - **HTTP server access logs.** Most servers log the full request path and query string by default. Anyone with log access has the URL. - **Reverse proxies and CDNs.** Cloudflare, Fastly, your load balancer — all log the URL, each with its own retention policy. - **Log aggregation pipelines.** Access logs rarely stay on one machine; they're shipped to centralized logging and monitoring services, multiplying the number of systems holding the URL. - **Referer headers.** When the page links to a third-party resource, the browser can send the source URL in the `Referer` header. Analytics scripts, embedded videos, and ad pixels all receive it. - **Browser extensions.** Extensions with "read browsing history" permission see every URL, including fragments. - **Bookmark sync.** Bookmarked URLs sync across the user's devices and to the browser vendor's servers. - **URL preview unfurlers.** Slack, Teams, iMessage, LinkedIn, and email clients fetch URLs to render previews — silently, the moment the message is sent. - **Corporate proxies and email gateways.** Many organizations inspect, rewrite, and log every URL that crosses their boundary. ## What HTTPS does and doesn't protect Worth being precise, because "the connection is encrypted" gets misread as "the URL is private." TLS encrypts the path and query string in transit: a network observer between the browser and the server cannot read `/reset?token=...`. What TLS does *not* hide: the destination hostname (visible via DNS resolution and the TLS SNI field on most connections today), and anything at the endpoints — the browser still records the full URL in history, and the server still writes it to its access log. Encryption in transit protects the wire, not the two ends, and the two ends are where URLs leak. ## A worked example: one URL's life Trace a single sensitive URL — say a reset link, `https://example.com/reset?token=8f3a91...` — from send to click: 1. **The mail provider** stores the message (URL included) indefinitely, and its security scanner may fetch the URL on delivery. 2. **The recipient's email gateway** rewrites and logs the URL, then fetches it again at click time. 3. **DNS** resolves `example.com` — the hostname (not the path) is now in resolver logs. 4. **The web server** writes the full request line to its access log. A default nginx/Apache "combined" format entry looks like: ```text 203.0.113.7 - - [14/Jul/2026:09:12:45 +0000] "GET /reset?token=8f3a91... HTTP/1.1" 200 5123 "-" "Mozilla/5.0 ..." ``` 5. **The CDN in front of it** logs the same URL with its own retention. 6. **The page's analytics script** records the page URL — query string and all — in a third-party system, unless explicitly configured to strip it. 7. **The browser** stores the URL in history and syncs it. One send, seven copies, held by at least five organizations. None of this required an attacker — it's the web working as designed. ## Referer header in practice If your secret reveal page links to any external resource (a CDN font, an analytics script, an embedded image), the browser may send the page's URL in the `Referer` header to that origin. Modern browsers default to `strict-origin-when-cross-origin`, which trims cross-origin referrers to just the origin (`https://example.com/` rather than the full path). That's real progress, but not something to rely on: same-origin requests still carry the full URL, a page-level policy can loosen the default, and older clients and embedded webviews vary. Two practical mitigations: ```html <!-- Strip the referer for outbound requests on the page --> <meta name="referrer" content="no-referrer" /> ``` ```http Referrer-Policy: no-referrer ``` The header version applies sitewide; the meta tag applies to the specific page. Use both for defense in depth — and better still, serve sensitive pages with **no third-party resources at all**, so there is nothing to send a referrer to. ## Path vs query vs fragment Where you put a token in the URL changes who sees it: <table> <thead> <tr><th>Location</th><th>Sent to server?</th><th>In server logs?</th><th>In Referer?</th><th>In browser history?</th></tr> </thead> <tbody> <tr><td>Path (<code>/s/abc123</code>)</td><td>Yes</td><td>Yes</td><td>Policy-dependent</td><td>Yes</td></tr> <tr><td>Query (<code>?token=abc123</code>)</td><td>Yes</td><td>Yes</td><td>Policy-dependent</td><td>Yes</td></tr> <tr><td>Fragment (<code>#abc123</code>)</td><td>No</td><td>No</td><td>No</td><td>Yes</td></tr> </tbody> </table> The fragment is genuinely different: per RFC 3986 it's processed client-side and never included in the HTTP request, which is why end-to-end encrypted paste tools put the decryption key there — the server literally never receives it. It's still not invisible: browser history, extensions, and any JavaScript running on the page can read it. Path versus query, by contrast, is a distinction without a privacy difference — both land in the same logs. ## The password-reset-token problem Sensitive tokens in URLs are a recognized vulnerability class — CWE-598 covers exactly this: sensitive data in query strings ends up in logs, histories, and referrers regardless of transport encryption. It's why well-built password-reset flows never rely on the secrecy of the URL alone. They make the token **single-use**, **short-lived**, and **bound to a subsequent action** (setting a new password), so a token recovered from a log three weeks later is worthless. That's the general lesson: you usually cannot keep a URL out of the logs, but you can make the logged URL worthless by the time anyone reads it. ## Designing URLs that are safe to leak Assume every URL you mint will eventually surface somewhere unintended, and design so that it doesn't matter: - **One-time consumption.** Burn the secret after the first successful read so a leaked URL is dead by the time it appears in someone's history. - **Short expiry.** Bound the leakage window. A URL that worked for five minutes is worth far less than one that worked for a week. - **Out-of-band passphrase.** Require a secret that was never in the URL. Now the URL alone — the only thing the logs have — is insufficient. - **Separate fetch from reveal.** Serve metadata on `GET` and release the payload only on an explicit `POST`, so preview bots and scanners can't consume the secret. - **No third-party resources on sensitive pages**, plus `Referrer-Policy: no-referrer` and `<meta name="robots" content="noindex">`. - **Redact secret routes in your own logs.** In nginx, map the request URI before logging: ```nginx map $request_uri $loggable_uri { ~^/s/ "/s/[redacted]"; default $request_uri; } log_format redacted '$remote_addr - $remote_user [$time_local] ' '"$request_method $loggable_uri" $status'; access_log /var/log/nginx/access.log redacted; ``` You control only your own logs — the CDN, proxy, and browser copies remain — which is exactly why the first three items on this list carry most of the weight. ## How this shapes secret links This threat model is why LinkPilot's Secret Links work the way they do: the URL is treated as inevitably-leaked, so the URL alone is never enough. A `GET` returns only metadata; the payload requires an explicit `POST` reveal, optionally gated by a passphrase that's SHA-256 hashed client-side. Burned, expired, or revoked secrets return HTTP 410 with the payload irreversibly overwritten, reveal responses carry `Cache-Control: no-store`, and view events log a hashed IP under a daily-rotating salt rather than the raw address. And one candid limit, stated on the [security architecture](/security-architecture) page: the decryption key rides in the URL fragment, so the whole link has to be treated as the secret — which is exactly the hazard this article is about. Short expiry, burn-after-read, and an out-of-band passphrase are what limit the damage when a link leaks. *Update, 29 September 2026: this paragraph originally said LinkPilot did not offer end-to-end encryption. It now encrypts text payloads in the browser, attachments included.* [[tool:burn-after-read-secret]] ## Limits URL design can't fix everything. It doesn't control what the recipient does after a legitimate read, it can't purge copies that third parties already hold, and it won't save a URL that carries personal data in plain sight — if a user's email address is in the query string, no expiry makes that unlogged. The durable rule: never put data in a URL that you'd need to delete later, because deleting a URL from everywhere it has been copied is practically impossible. Design URLs that are worthless when leaked instead. ## Related reading - [How one-time secret links work](/blog/how-one-time-secret-links-work) - [Link scanners and one-time secrets](/blog/link-scanners-and-one-time-secrets) - [Secure password sharing: 5 methods compared](/secure-password-sharing) Q: Is HTTPS enough to keep URL parameters private? A: HTTPS encrypts the URL in transit, but the URL is still logged in browser history, server access logs, and shared via Referer headers when the page links out. Encryption in transit doesn't make a URL secret. Q: What about fragment identifiers (#)? A: Fragments aren't sent to the server, which is why some end-to-end encrypted tools put the key in the fragment. They're still visible to browser extensions and any JavaScript on the page. Q: Should I put a token in the path or the query string? A: Neither is meaningfully more private. Both end up in the same logs and analytics. If the token must be in the URL, treat the whole URL as the secret and use one-time semantics. Q: Do modern browsers still send the full URL in the Referer header? A: Cross-origin, modern browsers default to strict-origin-when-cross-origin, which trims the referrer to just the origin. But same-origin requests still carry the full URL, a page can loosen the policy, and embedded webviews vary — so set Referrer-Policy: no-referrer explicitly on sensitive pages rather than relying on defaults. Q: How long do URLs live in server logs? A: As long as the retention policy says — commonly weeks to months — and access logs are routinely shipped to log-aggregation services, so copies exist in systems the site owner doesn't directly run. Assume any URL that reached a server is stored in several places you can't enumerate. ### Secure Link Sharing for Developers — https://uselinkpilot.com/blog/secure-link-sharing-for-developers Published: 2026-05-26 · Updated: 2026-07-14 · By W. Miller A practical guide for engineering teams — when to use one-time links, how to script them, and how to integrate them into onboarding and CI. If you're an engineer, secret-sharing usually shows up in three places: **onboarding**, **vendor hand-off**, and **incident response**. Here's a developer's-eye view of when to reach for a one-time link, when to skip it, and how to script it without leaking the secret into your shell history along the way. ## When to use a one-time link - Onboarding a new engineer with their first set of credentials. - Sharing a temporary admin password during an incident. - Delivering a vendor or contractor token that should not live in your vault. - Rotating a credential where the old value should die promptly. - Sending a customer the API key you provisioned for them. ## When not to use a one-time link - **Machine-to-machine secrets.** CI environment variables, K8s secrets, and Vault dynamic credentials are the right primitive there. A link is for the human hand-off into those systems. - **Long-lived team credentials.** Those belong in a password manager. - **Public configuration.** Don't dress up non-secret config as a secret. Use a regular link. The dividing line: if both ends of the transfer are machines, use your platform's secret store. If at least one end is a human, a one-time link is usually the cleanest primitive. <table> <thead> <tr><th>Situation</th><th>Right primitive</th></tr> </thead> <tbody> <tr><td>New engineer's first credentials</td><td>One-time secret link</td></tr> <tr><td>CI pipeline needs a deploy token at runtime</td><td>CI secret store / env vars</td></tr> <tr><td>Pod needs a database password</td><td>K8s secret / external secrets operator</td></tr> <tr><td>Team login used daily by five people</td><td>Password manager (shared vault)</td></tr> <tr><td>Customer needs their provisioned API key</td><td>One-time secret link</td></tr> <tr><td>Secret needed inside a git repo</td><td>Never — reference a secret store; add scanning to CI</td></tr> </tbody> </table> ## Scripting it LinkPilot has a REST API (available on paid plans). Issuing a secret from a script looks like this: ```bash LP_KEY=lp_live_... URL=$(curl -sS https://api.uselinkpilot.com/v1/secrets \ -H "Authorization: Bearer $LP_KEY" \ -H "Content-Type: application/json" \ -d '{ "payload": "'"$NEW_DB_PASSWORD"'", "expires_in": 3600, "burn_after_read": true, "passphrase": "'"$ONBOARDING_PASSPHRASE"'" }' | jq -r '.url') echo "Secret link: $URL" ``` Pipe that URL into whatever delivery channel you already use — Slack DM, email, your onboarding tool's webhook. ### Keeping the payload out of the process list The snippet above has a classic flaw: interpolating the payload into `-d` puts it on curl's command line, where any local user can read it via `ps` while the request runs. Build the JSON with `jq` and feed it over stdin instead: ```bash set -euo pipefail jq -n --arg payload "$NEW_DB_PASSWORD" \ --arg pass "$ONBOARDING_PASSPHRASE" \ '{payload: $payload, expires_in: 3600, burn_after_read: true, passphrase: $pass}' | curl -sS https://api.uselinkpilot.com/v1/secrets \ -H "Authorization: Bearer $LP_KEY" \ -H "Content-Type: application/json" \ -d @- | jq -r '.url' ``` Three habits worth making reflexive: - Values arrive via environment variables or a secrets manager CLI — never typed into an interactive shell where they land in history. - The script prints the *link*, never the payload. - `set -euo pipefail` so a failed API call can't silently hand an empty URL to the next step. ## Onboarding template A pattern that works well for new engineers on day one: 1. Onboarding script provisions accounts and pulls one-time credentials. 2. Script creates a secret link per credential with a 4-hour expiry and a shared passphrase. 3. Script sends an email with all the links and a Slack DM with the passphrase. 4. Engineer opens each link, copies the credential into their password manager. 5. Anything unread by end-of-day gets revoked and reissued at their pace. Why these parameters: the 4-hour expiry covers a normal first morning without leaving credentials live overnight; the passphrase travels by a second channel so a forwarded or misdelivered email is harmless; burn-after-read means the engineer's mailbox ends the day containing only dead URLs. Tell the new hire explicitly: *"each link works once — save the value into your password manager before closing the tab."* The most common onboarding failure is a recipient who reads the secret, closes the tab, and assumes they can come back later. ## A rotation runbook Rotating a shared database password with a contractor or teammate on the receiving end: 1. Generate the new password and apply it in the source system (database, cloud console, wherever it's canonical). 2. Update your own consumers first — CI vault, K8s secret, app config — so nothing breaks while the human hand-off happens. 3. Create a one-time link for the new value: burn after read, 1-hour expiry, passphrase. 4. Deliver link and passphrase through different channels. 5. Verify the view event in the audit timeline. No view before expiry? Revoke and reissue — never re-send the same link. 6. Confirm the old credential is disabled at the source. Each rotation gets its own link. Links are independent by design — that's a feature for delivery and a non-feature for governance, so the rotation *schedule* lives in your manager or runbook, not in the link tool. ## Incident response During an incident you often need to rotate a credential and distribute the new one to a few responders fast. Don't paste it in the incident channel — that channel is being recorded for the postmortem, and the secret will end up in the export, the retro doc, and every retention system downstream of them. - Rotate the credential in the source system. - Issue a secret link with a 30-minute expiry. - Drop the link in the channel; send the passphrase by DM. - After the incident, confirm the link is burned or revoked. The postmortem then contains a dead URL instead of a live admin password — and the audit trail gives the timeline reviewer an exact "credential re-issued at 14:32, read at 14:33" record for free. One unfurl-related note: chat clients fetch pasted URLs to render previews. A well-designed secret link survives this because the preview fetch is a `GET` and the reveal is an explicit `POST` — see [link scanners and one-time secrets](/blog/link-scanners-and-one-time-secrets) for the full mechanics. If you're evaluating a tool, test this before an incident, not during one. ## What the audit trail gives you Every LinkPilot secret carries an event timeline: created, viewed, failed_passphrase, burned, expired, revoked. Views are recorded with a timestamp, coarse geolocation when available, the user agent, and a hashed IP (SHA-256 with a daily-rotating salt — the raw IP is never stored). In practice that gives you three answers scripts and runbooks can rely on: - **Delivery confirmation** — a viewed event means the hand-off happened. - **Anomaly detection** — a failed_passphrase burst or a view you don't recognize is your cue to rotate immediately. - **A clean record for reviews** — "delivered once, read once, burned" is a sentence auditors like. ## Limits: what links don't solve - **They're not a vault.** Nothing about a one-time link manages ongoing access, rotation schedules, or who-has-what inventories. - **The link is the key.** LinkPilot encrypts text payloads in your browser and never receives the key, but that key travels in the URL fragment — so anyone who obtains the full link can read the secret, and a lost link means the secret is unrecoverable. Attached files are encrypted the same way, though their names and sizes are not. Short expiry plus burn-after-read still matters. *Update, 29 September 2026: this bullet previously read "they're not end-to-end encrypted", which was accurate until that date.* Details on the [security architecture](/security-architecture) page. - **They don't fix secret sprawl in code.** Keys hardcoded in repos need scanning and rotation, not a better delivery mechanism. - **They can't protect the far end.** Once a human has read the value, treat it as living wherever they put it. [[tool:free-secret-link-generator]] ## Related reading - [How to share API keys securely](/blog/how-to-share-api-keys-securely) - [Expiring links: why short windows matter](/blog/expiring-links-security) - [LinkPilot Security Architecture](/security-architecture) Q: Can I create secret links from a script? A: Yes. LinkPilot exposes a REST API (paid plans) so you can issue secrets from onboarding scripts, CI jobs, or internal tooling. Each call returns a URL you can pipe into email, Slack, or SMS. Q: Should secrets ever live in environment variables in CI? A: Yes — that's still the correct primitive for CI runtime. Use secret links for the human-to-human hand-off (giving the engineer the initial credential to put into the CI vault), not for the machine-to-machine path. Q: How do I handle rotation in scripts? A: Generate a fresh credential in the source system, push it into a one-time link, send the link, and let the recipient store it in their manager or CI vault. Don't re-use links across rotations — each rotation gets its own link. Q: Won't the secret end up in my shell history or process list? A: That's the real risk with naive scripting: command-line arguments are visible to other local users via ps while the command runs, and interactive shells write history files. Pass payloads on stdin (curl -d @-) and keep API keys in environment variables, never in flags. Q: How do I confirm the recipient actually received the credential? A: Check the secret's audit timeline. A viewed or burned event with a timestamp confirms delivery; a secret that expires with no view event means delivery failed — revoke and reissue rather than guessing. ### Secret Links vs Password Managers — https://uselinkpilot.com/blog/secret-links-vs-password-managers Published: 2026-05-26 · Updated: 2026-07-14 · By W. Miller Password managers and one-time secret links solve different problems. Here's when to use each — and why most teams need both. Short answer: a password manager is for **storing** credentials a team uses repeatedly. A one-time secret link is for **handing off** credentials once. Most security-aware teams use both, and most of the friction comes from using one where the other belongs. ## The jobs each one is built for <table> <thead> <tr><th>Job</th><th>Password manager</th><th>Secret link</th></tr> </thead> <tbody> <tr><td>Indefinite storage</td><td>Yes</td><td>No</td></tr> <tr><td>Sharing with non-vault users</td><td>Awkward</td><td>First-class</td></tr> <tr><td>One-time delivery</td><td>Possible</td><td>Default behavior</td></tr> <tr><td>Rotation tracking</td><td>Yes</td><td>No</td></tr> <tr><td>Audit log of every read</td><td>Limited</td><td>Per-secret</td></tr> <tr><td>Works without recipient signup</td><td>No</td><td>Yes</td></tr> <tr><td>Browser and CLI autofill</td><td>Yes</td><td>No</td></tr> <tr><td>Guaranteed forgetting after hand-off</td><td>No</td><td>Yes — burn or expiry</td></tr> </tbody> </table> A manager is a system of record. A secret link is a delivery mechanism with strong forgetting semantics: after the hand-off, the link burns, expires, or gets revoked, and the URL left behind in chat or email points at nothing. ## When the password manager wins - The credential will be used repeatedly by a known team. - You want a single canonical copy that updates everywhere. - The recipient is already in your vault. - You need autofill in browsers and CLI tools. - You want breach-monitoring and weak-password reports across the whole credential inventory. ## When the secret link wins - The recipient is a contractor, customer, or vendor not in your vault — and never will be. - You only need to deliver the credential once. - You want a clear "this was read at 14:32" audit event for the hand-off, tied to that specific delivery. - The credential is a short-lived token, OTP, or rotation secret that should not linger anywhere. - You need the sensitive value *out* of the channel you're forced to use. Email and chat retain everything; a burned link retains nothing. ## Pick by scenario <table> <thead> <tr><th>Scenario</th><th>Reach for</th><th>Why</th></tr> </thead> <tbody> <tr><td>Teammate in your vault needs the staging login</td><td>Password manager</td><td>Share the vault item; it stays current after rotation</td></tr> <tr><td>Contractor needs a database password for a two-week engagement</td><td>Secret link</td><td>No vault seat needed; delivery is auditable; nothing lingers</td></tr> <tr><td>New hire's day-one credentials</td><td>Both</td><td>Values live in the manager; the hand-off travels by one-time link</td></tr> <tr><td>Customer needs the API key you provisioned for them</td><td>Secret link</td><td>Customers are never in your vault; email would retain the key forever</td></tr> <tr><td>Incident responder needs the rotated admin password now</td><td>Secret link</td><td>Short expiry; the incident channel only ever holds a dead URL</td></tr> <tr><td>Wi-Fi password for the office</td><td>Password manager (shared vault)</td><td>Long-lived, low-sensitivity, needed repeatedly</td></tr> </tbody> </table> ## Three worked examples ### Contractor hand-off 1. Pull the credential from the manager (or better, mint a scoped, time-boxed credential just for the contractor). 2. Create a one-time secret link: burn after one view, 24-hour expiry, passphrase set. 3. Email the link; send the passphrase by text or a Slack DM. 4. Watch for the view event. Once it's read, the link is dead and the email thread contains nothing sensitive. 5. When the engagement ends, revoke the credential at the source. ### New-hire onboarding The manager holds the canonical values. The hand-off problem is that the new hire isn't in the vault yet — their first credential *is* vault access. Deliver that bootstrap credential through a one-time link with a same-day expiry; everything after that flows through the manager like normal. ### Customer API key delivery Never email the key itself: email is stored indefinitely on multiple servers and is a primary target in account takeovers. Generate the key, send a one-time link, and let the burn event double as delivery confirmation. If the link expires unread, you know delivery failed *before* the customer complains — reissue with a fresh link. ## The combined pattern most teams settle on 1. The team's long-lived credentials live in the password manager (1Password, Bitwarden, Vaultwarden). 2. When someone outside the vault needs a credential, an authorized team member pulls it from the manager and sends a one-time [secret link](/tools/free-secret-link-generator) with a short expiry. 3. The recipient stores the credential in *their* manager. 4. The link burns. The manager retains the canonical copy and the rotation history. This way the audit story is split correctly: the manager owns "who has access to what" and the link owns "when did the hand-off happen, and was it read by exactly one party." ## What about managers' built-in share links? Several managers now ship their own expiring share features — 1Password item sharing, Bitwarden Send (as published July 2026; verify current docs before relying on specifics). If your whole world is inside one manager, these are legitimate and convenient. A dedicated secret link still earns its place when you want a passphrase gate delivered out-of-band, a per-secret audit timeline you can point to later, unfurl-safe behavior in chat and email, or a tool that doesn't assume anything about which manager (if any) the other side uses. ## What about rotation? A secret link doesn't track rotation. If you share the same value twice through two different links, neither link knows the other exists. That's fine for the hand-off but useless for ongoing governance — keep that responsibility in the manager, and treat every rotation as a fresh hand-off with a fresh link. ## Limits and honest caveats - **A secret link is not storage.** If the recipient doesn't save the value into their own manager before the link burns, you're reissuing it. Say so explicitly when you send it. - **Neither tool survives the recipient.** Once a human has read a credential, they can copy it anywhere. Both tools protect the *transport and storage*, not the far end. - **Know your provider's encryption model.** Reputable password managers encrypt vaults end-to-end, and so does LinkPilot for Secret Link text payloads: the content is encrypted in your browser and the key stays in the URL fragment, so an operator cannot read an active secret. Passphrases are hashed client-side and burned payloads are irreversibly overwritten. Attached files are encrypted the same way. *Update, 29 September 2026: this bullet previously said Secret Links were not end-to-end encrypted, which was accurate until that date.* The details are on the [security architecture](/security-architecture) page. - **The manager's master password is a single point of failure.** That's the price of a system of record; protect it with a strong passphrase and hardware-backed 2FA. [[tool:free-secret-link-generator]] ## Related reading - [How to share API keys securely](/blog/how-to-share-api-keys-securely) - [Secure password sharing: 5 methods compared](/secure-password-sharing) - [LinkPilot vs OneTimeSecret](/compare/linkpilot-vs-onetimesecret) Q: Can I just share a vault item instead of using a link? A: For long-lived credentials shared with someone who also uses the manager, yes. For one-off hand-offs to people outside the vault (contractors, customers, vendors), a one-time link is faster and leaves a cleaner trail. Q: Is a password manager more secure than a secret link? A: For storage, yes — managers are designed for indefinite secure storage. For ad-hoc delivery to a non-vault user, the manager's secure-share feature and a one-time link are roughly equivalent. Q: What about rotating secrets? A: Managers track rotation history. One-time links don't — every share is independent. Use the manager as the system of record and the link only for the hand-off. Q: Don't password managers have their own share-link features? A: Several do — 1Password item sharing and Bitwarden Send create expiring share links (as published July 2026; verify current docs). If everyone involved already uses the same manager, they're a fine choice. A dedicated secret link adds a passphrase gate, a per-view audit event, and works regardless of which manager either side uses. Q: What if the recipient loses the link before opening it? A: Nothing is lost except time. Revoke the unread secret so the old URL is permanently dead, then issue a fresh link. Never re-send the same link — and if the audit trail shows the first link was viewed by someone else, rotate the credential. ### Link Scanners and One-Time Secrets — https://uselinkpilot.com/blog/link-scanners-and-one-time-secrets Published: 2026-05-26 · Updated: 2026-07-14 · By W. Miller How URL unfurlers and security scanners can accidentally burn one-time secrets — and the patterns that defend against it. If your one-time link is consumed on `GET`, it dies the moment Slack unfurls it. Here's why it happens, which systems fetch your links without asking, and how to design around all of them. ## The default failure mode Most chat and email clients try to render a preview when they see a URL. The flow looks like this: 1. User pastes the secret link into Slack. 2. Slack's unfurler fetches the URL (issues `GET`). 3. Your reveal handler treats the request like a human view, burns the secret, and returns the payload. 4. Slack receives the burned payload (or a generic page) and renders it. 5. The human clicks the link, sees "already viewed," and pings the sender for a new one. The unfurler had no malice. Your handler conflated "someone fetched the URL" with "the recipient read the secret." Those are different events, and the entire design problem is keeping them apart. There's a worse variant hiding in step 3: if the unfurler's `GET` received the actual payload, the secret now sits inside a third party's preview-rendering infrastructure. Best case, it was discarded after the preview was built — but you have no way to confirm that, and no audit event telling you it happened. ## Who actually fetches your links "Slack unfurls previews" understates the problem. A URL pasted into a modern workplace is typically fetched by several systems before any human clicks it: <table> <thead> <tr><th>Fetcher</th><th>When it fires</th><th>Identifiable?</th></tr> </thead> <tbody> <tr><td>Chat unfurlers (Slack, Teams, iMessage, WhatsApp, LinkedIn)</td><td>The moment the message is sent</td><td>Usually — distinct user agents such as <code>Slackbot-LinkExpanding</code></td></tr> <tr><td>Email security gateways (Mimecast, Proofpoint, Microsoft Defender)</td><td>On delivery, and often again at click time</td><td>Often not — many present real browser user agents</td></tr> <tr><td>Endpoint protection / antivirus</td><td>When the URL reaches the recipient's machine</td><td>Rarely</td></tr> <tr><td>Corporate web proxies</td><td>At click time, before the user's request is forwarded</td><td>Rarely</td></tr> <tr><td>Link-preview browser extensions</td><td>On hover or page load</td><td>No — they ride the user's own browser session</td></tr> </tbody> </table> Vendor behavior in this table is a moving target — treat specific gateway claims as "as published July 2026, verify against current docs." The common thread doesn't move, though: every one of these systems issues a plain `GET`, because that's the only safe, universal way to look at a URL you don't control. ## The fix: separate fetch from reveal The HTTP semantics are already there. RFC 9110 defines `GET` as safe and idempotent — a request anyone may issue freely because it isn't supposed to change anything. `POST` is the action verb. So treat the reveal as a `POST` action behind a visible button: ```http GET /s/abc123 → HTML page: "Click to reveal this secret" POST /s/abc123 → burns the secret, returns the payload ``` Now Slack's `GET` returns a neutral metadata page. The secret only dies when the human clicks the button. Any scanner that respects HTTP semantics — nearly all of them, since issuing side-effectful `POST`s against arbitrary URLs would break half the web — never touches the payload at all. ## A worked trace Follow one link end to end. You create a secret with burn-after-read and a passphrase, then paste the URL into a Slack DM and an email. 1. **Slack's unfurler** issues `GET /s/abc123`. Response: a small metadata page — status active, passphrase required. No view recorded. Secret alive. 2. **The recipient's email gateway** rewrites the URL in the email and fetches it at delivery time for reputation analysis. Same `GET`, same metadata. Still alive. 3. **The recipient clicks the emailed link.** The gateway's click-time scanner fetches once more (`GET`), then redirects the browser onward. 4. **The browser loads the reveal page** — another `GET`. The page shows a reveal button and a passphrase field. Still no view recorded. 5. **The recipient enters the passphrase and clicks reveal.** The browser issues `POST /s/abc123`. The view is recorded, the payload is returned, the secret burns. 6. **Anyone fetching the URL afterward** gets an explicit "already viewed and destroyed" response instead of content. Five fetches, one reveal. That ratio is normal in a corporate environment — any design that can't tolerate it will fail on day one, and the sender will just paste the password into chat instead. ## Layered defenses ### The GET / POST split Handles every well-behaved unfurler and scanner, which is the overwhelming majority of automated traffic. This is the foundation; everything below is depth. ### Passphrase gate Covers what the split can't: sandboxes that execute JavaScript and interact with the page, plus accidental human clicks and forwarded emails. A detonation sandbox can click a reveal button; it cannot supply a passphrase that traveled through a different channel. Send the link by email and the passphrase by Slack DM or SMS. ### Bot user-agent filtering Drop known preview bots (`Slackbot`, `LinkedInBot`, `Twitterbot`) before they reach any reveal logic. Worth doing as belt and braces, but never sufficient alone: security scanners routinely present real browser user agents precisely so malicious pages can't cloak themselves from analysis. ### Short expiry Bound the damage window. A link that lived for fifteen minutes leaves scanners, log files, and chat history holding a URL that no longer resolves to anything. ### Cache-Control: no-store Set it on every reveal response so no intermediary — corporate proxy, CDN, browser cache — retains a copy of the payload after the one legitimate read. ## Email security gateways specifically Corporate gateways deserve their own section because they fetch twice. Products in this class rewrite every URL in inbound mail through their own scanning domain. The URL is typically fetched once at delivery for reputation analysis, and again at click time, before the human is redirected to the real destination. If either fetch burned the secret, the recipient would *always* see a dead link — a failure mode that looks random to users but is completely deterministic. The `GET`/`POST` split absorbs both fetches for free, since both are plain `GET`s. The click-time redirect then lands the human on the reveal page, where the `POST` happens. ## Edge cases that still bite - **JavaScript-executing sandboxes.** Some detonation environments render the page and interact with it. A `POST` behind a button *without a passphrase* could, in principle, be clicked by an aggressive sandbox. The passphrase gate is the backstop. - **Link and passphrase in the same channel.** If both travel in one email, every defense above collapses to "hope nobody reads that email." Always split channels. - **Forwarding.** Every forward into a new chat or mail system triggers a fresh round of unfurls. Harmless with the split — but each hop is another set of logs holding the URL, which is an argument for short expiry. - **Concurrent reveals.** If two people click reveal simultaneously, the burn must be atomic: exactly one request wins and the other gets "already viewed." A non-atomic implementation can serve the payload twice. ## Test your own tool Before trusting any secret-sharing service with real credentials, run this two-minute check: 1. Create a throwaway secret with burn-after-read enabled. 2. Fetch it from a terminal — this is exactly what an unfurler does: `curl -s -o /dev/null -w "%{http_code}" "<url>"` 3. Open the link in a browser. If you see "already viewed," the tool burns on `GET` and is not safe to paste into chat or email. 4. If it survived, reveal it properly in the browser, then `curl` again — you should now get an explicit gone/burned response, not the payload. ## How LinkPilot implements this For the record, this is the design LinkPilot's Secret Links use: a `GET` on the reveal endpoint returns metadata only (status, and whether a passphrase is required); a view is recorded only on an explicit `POST` reveal. Passphrases are SHA-256 hashed client-side and rate-limited to five attempts per IP per minute per secret. Every reveal response carries `Cache-Control: no-store`, burned or expired secrets return HTTP 410 with the stored payload overwritten, and the audit timeline records each event with a hashed IP under a daily-rotating salt — the raw IP is never stored. Full details live on the [security architecture](/security-architecture) page. [[tool:burn-after-read-secret]] ## Limits of this design Honest boundaries: none of the above protects a secret *after* a legitimate reveal — the recipient can copy, screenshot, or forward the payload itself. It doesn't help if the passphrase travels with the link. And it can't stop a human who was mistakenly sent the link from opening it before the intended recipient does — that's what the audit trail is for: you see the unexpected view, and you rotate the credential. ## Related reading - [How one-time secret links work](/blog/how-one-time-secret-links-work) - [Why URLs leak sensitive information](/blog/why-urls-leak-sensitive-information) - [LinkPilot Security Architecture](/security-architecture) Q: Which clients are the worst offenders? A: Anything that unfurls URLs: Slack, Microsoft Teams, iMessage, LinkedIn DMs, WhatsApp web previews, and most email security gateways (Mimecast, Proofpoint, Microsoft Defender). They all fetch the URL on receipt. Q: Can I detect unfurlers by user agent? A: Partially. Well-behaved bots send identifiable user agents (Slackbot-LinkExpanding, LinkedInBot, Twitterbot). Security scanners often spoof real browsers, so user-agent filtering alone is insufficient. Q: Is GET-vs-POST a complete fix? A: It handles the unfurler case completely, since unfurlers only issue GET. It doesn't handle a human accidentally clicking and burning the secret — for that you also need the passphrase gate. Q: Do email scanners ever click buttons on the page? A: Some detonation sandboxes execute JavaScript and can interact with a page, so a bare reveal button is not a guarantee. That's why the passphrase gate matters: a sandbox cannot supply a passphrase that traveled through a different channel. Q: How do I test whether a secret-sharing tool is unfurl-safe? A: Create a throwaway secret, fetch its URL once with curl (a plain GET — exactly what an unfurler does), then open it in a browser. If the browser shows 'already viewed,' the tool burns on GET and is not safe to paste into chat or email. ### How to Share API Keys Securely — https://uselinkpilot.com/blog/how-to-share-api-keys-securely Published: 2026-05-26 · Updated: 2026-10-04 · By W. Miller Practical patterns for sharing API keys with teammates and contractors without leaving the secret in chat or email history. The shortest version: **don't paste the key into chat or email**. Send a [one-time secret link](/tools/free-secret-link-generator) instead: the key is encrypted in your browser, the decryption key stays in the URL fragment, and the stored secret is destroyed after it is opened. Then rotate any key that was already pasted in plaintext. The rest of this guide is the detail: why the obvious channels fail, the exact hand-off procedure, what to do when a key leaks anyway, and the cases where a one-time link is the wrong tool. ## Why chat and email fail - **Both are searchable forever.** A key shared in 2023 is a key your next incident is sourced from. Attackers who land in a corporate chat or mailbox routinely search it for exactly the strings API keys look like — `sk_live`, `AKIA`, `ghp_`, `Bearer`. - **Both sync everywhere.** Phones, personal laptops, tablets — devices that are out of scope for your security controls and out of reach for your remote-wipe policy. - **Both get exported.** Compliance reviews, legal discovery, and workspace exports all produce copies of history. Every export is another place the key lives. - **Both survive offboarding.** The contractor's engagement ends; the DM thread with your Stripe key in it does not. Putting a secret into either tool means accepting that the secret lives wherever the message ends up, for as long as anything retains it. Neither system was designed to forget. ## Before you share: shrink the key The best hand-off is one where the key being handed off barely matters. Before generating anything, apply least privilege at the source: - **Scope it.** Stripe restricted keys, GitHub fine-grained personal access tokens, AWS IAM policies scoped to specific actions and resources — most serious providers let you mint a key that can do only the one thing the recipient needs. - **Prefer read-only** unless writes are genuinely required. - **Set provider-side expiry** where the platform supports it (GitHub fine-grained PATs, AWS temporary credentials via STS). Then even a leaked key has a shelf life independent of anything you do downstream. - **Name it after the recipient** (`vendor-x-readonly`) so that six months from now, revoking it is a one-look decision instead of an archaeology project. A scoped, expiring, read-only key turns a worst-case leak from an incident into an annoyance. ## The hand-off pattern 1. **Generate the key in the source system** (AWS, Stripe, your own API) with the minimum scopes, per above. 2. **Paste it into a one-time secret link** with burn-after-read on and the shortest expiry that fits: 1 hour is the shortest preset, with 24 hours and 7 days behind it and a custom date and time on Pro — just long enough for the actual hand-off, no longer. 3. **Add a passphrase, delivered through a different channel** — link by email, passphrase by SMS or Slack DM. In LinkPilot the passphrase, custom expiry and the audit timeline are Pro features at $29/mo. If either channel leaks, the attacker still has only half the puzzle. (LinkPilot hashes the passphrase in the browser with SHA-256 before it's sent; the raw passphrase never reaches the server's database or logs, and attempts are rate-limited to 5 per IP per minute.) 4. **Send the link.** 5. **Confirm out-of-band that the recipient retrieved it**, and check the audit timeline: one view, expected time, expected location. That's your receipt. If the link goes unread past the expiry, revoke it and resend — don't extend, and don't reuse. ## Example: passing a Stripe restricted key ```bash # generate a restricted key with the minimum needed scopes stripe api_keys create \ --restricted \ --display-name "vendor-x-readonly" # pipe the resulting key into a LinkPilot secret curl -X POST https://api.uselinkpilot.com/v1/secrets \ -H "Authorization: Bearer $LP_KEY" \ -d 'payload=sk_restricted_…' \ -d 'expires_in=3600' \ -d 'burn_after_read=true' ``` What the recipient experiences: opening the link shows a reveal page — not the key. Link unfurlers and email scanners that prefetch the URL get metadata only, because a view is recorded solely on the explicit reveal action, never on the `GET`. When the recipient clicks reveal (and enters the passphrase, if set), they see the key exactly once. After that, the stored payload is overwritten and the link returns HTTP 410. Even if the email forwards itself around the company, only the first viewer could ever have read it — and the audit trail shows you who that was. ## Which channel for which hand-off <table> <thead> <tr><th>Situation</th><th>Recommended method</th><th>Notes</th></tr> </thead> <tbody> <tr><td>Teammate, same room or on a call</td><td>One-time link, 1-hour expiry (the shortest preset)</td><td>Passphrase optional — you can confirm receipt live</td></tr> <tr><td>Remote teammate</td><td>One-time link + passphrase via second channel</td><td>1-hour expiry</td></tr> <tr><td>Contractor or agency</td><td>Scoped key + one-time link + passphrase</td><td>Name the key after them; calendar the revocation for engagement end</td></tr> <tr><td>Customer receiving their own key</td><td>One-time link from your app or support flow</td><td>24-hour expiry; instruct them to store it immediately</td></tr> <tr><td>CI/CD pipeline or service</td><td>Platform secret store (Actions secrets, Vault, ASM)</td><td>Never a link — machines don't do hand-offs</td></tr> <tr><td>Whole team, ongoing access</td><td>Password manager vault</td><td>This is storage and access control, not a hand-off</td></tr> </tbody> </table> ## If a key leaks anyway: the rotation runbook Treat any key that touched a chat message, email body, screenshot, git commit, or public paste as burned. In order: 1. **Issue the replacement key first**, if the provider allows two active keys — this avoids downtime for legitimate consumers. 2. **Revoke the leaked key at the provider.** This is the only step that actually ends the exposure; deleting the Slack message does not. 3. **Hand off the new key properly** — one-time link, passphrase, short expiry, per the pattern above. 4. **Check the provider's usage logs** for the leaked key between exposure and revocation. Unexpected calls mean this is now an incident, not a cleanup. 5. **Fix the source of the paste** — add the secret to your `.gitignore`d env tooling, enable secret-scanning in your repo host, or update the runbook that told someone to DM it. The whole loop should take minutes. If rotating a key is scary enough that people avoid it, that fragility is the real vulnerability — fix that first. ## What to avoid - **Re-sending the same secret.** Rotate instead. Re-sending erases the "exactly one exposure" audit story that made the one-time link worth using. - **Long expiry windows.** Default to short. Most hand-offs complete in minutes; an 8-hour window is just a longer leak. - **Skipping the passphrase.** It costs almost nothing and defends against accidental URL leaks — forwarded emails, screen shares, shoulder surfing on a shared screen. - **Screenshots of keys.** They land in camera rolls, cloud photo sync, and image search. A screenshot is chat-paste permanence with worse searchability for *you* and fine searchability for OCR. - **Using the link tool as storage.** The link is the courier, not the vault. The recipient should store the key in a password manager or env tooling the moment they receive it. ## When a one-time link is the wrong tool Honesty section — this pattern has edges: - **Machine-to-machine credentials** belong in a secrets manager or the platform's native store, injected at deploy or runtime. A human clicking a link is not a deployment step. - **Long-lived shared credentials** belong in a password manager with real access control and revocation per person. - **High-frequency rotation** (keys that change hourly) should be automated end to end; humans and links shouldn't be in that loop at all. - **Secrets you cannot afford to have any third party touch at all** — move the hand-off offline. *Update, 29 September 2026: this bullet originally said LinkPilot did not claim E2EE and to use an end-to-end encrypted tool instead. LinkPilot now encrypts text payloads in the browser, so it only ever stores ciphertext, and attached files along with them. The [Security Architecture](/security-architecture) page states exactly what is and isn't protected.* For the common case — one human handing one credential to another human, once — the one-time link with a passphrase and a short expiry is the strongest simple pattern available. ## Related reading - [Why URLs leak sensitive information](/blog/why-urls-leak-sensitive-information) - [Secure password sharing: 5 methods compared](/secure-password-sharing) - [LinkPilot Security Architecture](/security-architecture) - [URL shortener API comparison](/blog/url-shortener-api-comparison) - [Free secret link generator](/tools/free-secret-link-generator) Q: Is it really that bad to send an API key in Slack? A: It's not the act of sending — it's the permanence. Chat history is searchable, syncs to mobile, gets exported in compliance reviews, and survives offboarding. A one-time link removes the secret from the channel after a single read. Q: Should I just use a password manager? A: Yes, for long-lived credentials. Use a manager as the system of record and a one-time link only for the hand-off. Many teams use both — the link moves the key, the vault stores it. Q: What if the recipient needs the key again later? A: Don't re-send the original — issue a new key or have them store it in a manager when they receive it. Re-sharing defeats the rotation story and muddies the audit trail. Q: How do I get an API key into CI/CD? A: Not with a link. Machines should read from your platform's secret store — GitHub Actions secrets, GitLab CI variables, AWS Secrets Manager, Vault. One-time links are for human-to-human hand-offs only. Q: Can LinkPilot read the API key I share? A: No. Since 29 September 2026 the payload is encrypted in your browser and the key travels in the URL fragment, which browsers never send, so an operator with full database access sees only ciphertext. Burned payloads are overwritten and unrecoverable. The trade-off is that anyone holding the full link holds the key, so short expiry plus burn-after-read still matter. Attached files are encrypted the same way. The Security Architecture page states the whole model, including the metadata we can still see: a file's name, size and type. ### How One-Time Secret Links Work — https://uselinkpilot.com/blog/how-one-time-secret-links-work Published: 2026-05-26 · Updated: 2026-10-04 · By W. Miller A clear, developer-friendly explanation of how one-time secret links work — from creation to atomic burn-after-read. A one-time secret link is a self-destructing URL that reveals its contents exactly once and then becomes permanently inert. In LinkPilot the secret is encrypted in your browser with AES-GCM-256 before anything is sent: the server stores only ciphertext, and the decryption key travels in the URL fragment after `#k=`, which browsers never send to a server. The recipient's first reveal decrypts it in their browser and burns the stored ciphertext in the same operation. You can make one without an account with the [free secret link generator](/tools/free-secret-link-generator). The mechanism is simple, but the edge cases are where it gets interesting — and where sloppy implementations quietly leak. ## The basic flow 1. Sender pastes a secret. The browser generates a random key, encrypts the payload with AES-GCM-256, and sends only the ciphertext. The server stores it under a random, hard-to-guess slug and returns a URL; the browser appends the key as a `#k=` fragment, which never leaves the sender's device. 2. Sender shares the URL through any channel — email, chat, SMS. 3. Recipient opens the URL. A plain `GET` returns status only. When they click reveal, the server atomically marks the secret as consumed and returns the ciphertext in the same operation; the recipient's browser decrypts it with the key from the fragment. 4. Any subsequent visit gets a "burned" status page instead of content. The critical step is step 3. If the read and the status update happen as two separate queries — `SELECT` to check, then `UPDATE` to mark — two concurrent viewers can both pass the check before either one writes. Both get the payload. That's a classic TOCTOU (time-of-check to time-of-use) bug, and it converts your "exactly once" guarantee into "usually once." ## Atomicity in practice The fix is to collapse the check, the mark, and the read into one database operation. In Postgres that looks like: ```sql UPDATE secrets SET burned_at = now() WHERE slug = $1 AND burned_at IS NULL AND expires_at > now() RETURNING payload; ``` The row-level lock the `UPDATE` takes means concurrent callers serialize: the first one matches the `WHERE` clause, flips `burned_at`, and gets the payload back via `RETURNING`. Every later caller finds `burned_at` already set, matches zero rows, and gets the burned status. There is no window between "check" and "consume" because they are the same statement. LinkPilot records views atomically through a database function for exactly this reason — concurrent reveal attempts cannot leak the secret twice. If you're evaluating a tool, this is a fair question to ask the vendor directly: *is the burn atomic with the read?* ## What "burned" should look like: HTTP 410 Once consumed, the link should fail loudly and permanently. LinkPilot does two things on burn: - The stored payload is **overwritten** with `[REDACTED]` in the same write that flips the status — so even a later database compromise can't recover a spent secret. - Subsequent reveal attempts return **HTTP 410 Gone** with a clear "already viewed and destroyed" page. 410 is the right status code: it means the resource existed and is intentionally, permanently unavailable — as opposed to 404, which says "never heard of it." The distinction matters for humans too: a recipient who sees "this secret was already viewed" knows to tell the sender, who can check the audit trail and rotate if the viewer wasn't them. ## Hard-to-guess slugs, and why they aren't enough The slug is what stands between the public internet and an unread ciphertext (the key is in the fragment, not on the server), so it has to carry real entropy. A slug drawn from a cryptographically secure random source with, say, 22 characters of base62 carries roughly 128 bits — enumeration is not a realistic attack at any request rate a server would survive. But slug entropy only defends against *guessing*. It does nothing about the URL being *observed*: browser history, proxy logs, forwarded emails, screen shares, clipboard managers. That's why serious implementations layer on: - **Expiry**, so an observed URL goes dead on schedule. - **A passphrase**, so an observed URL alone isn't sufficient. - **Burn-after-read**, so an observed URL is worthless after the legitimate read. ## Link previews and bots Chat clients (Slack, Teams, iMessage) and email security scanners unfurl URLs by fetching them with a `GET` request the moment a message is delivered. If your reveal endpoint burns on `GET`, the unfurler destroys the secret before the human ever sees it — the most common real-world failure of naive burn-after-read tools. The defenses, as LinkPilot implements them: - **Separate metadata and reveal actions.** A `GET` on the reveal endpoint returns only status and whether a passphrase is required. A view is recorded only on an explicit `POST` — the action a human takes when they click the reveal button. - **Passphrase gate (Pro).** When a passphrase is set, no payload is returned to anyone — bot or human — without the correct hash. - **`Cache-Control: no-store`** on every reveal response, so intermediaries never cache secret contents. [LinkPilot's Security Architecture page](/security-architecture) documents this handling end to end. ## The lifecycle, state by state <table> <thead> <tr><th>State</th><th>Triggered by</th><th>What a visitor sees</th><th>Payload recoverable?</th></tr> </thead> <tbody> <tr><td>Active</td><td>Creation</td><td>Reveal page (passphrase prompt if set)</td><td>Yes — one reveal available</td></tr> <tr><td>Burned</td><td>View-count limit reached</td><td>"Already viewed and destroyed" — HTTP 410</td><td>No — payload overwritten</td></tr> <tr><td>Expired</td><td>Expiry deadline passes</td><td>Expired status page</td><td>No — redacted on next access</td></tr> <tr><td>Revoked</td><td>Sender kills it from the dashboard</td><td>Refuses to reveal — HTTP 410</td><td>No — immediate and permanent</td></tr> </tbody> </table> Every transition lands in the audit timeline, a Pro feature in LinkPilot. The event types are `created`, `viewed`, `failed_passphrase`, `burned`, `expired`, and `revoked`, each with a timestamp and a hashed IP (SHA-256 with a daily-rotating salt — the raw IP is never stored). That trail is what turns "I think they got it" into "viewed at 10:05 from the expected country, one view, then burned." ## Common extensions - **Passphrase gate** — require an out-of-band passphrase before the reveal, so a leaked URL alone is not a leaked secret. In LinkPilot this is a Pro feature ($29/mo), alongside custom expiry and the audit timeline; the no-account generator cannot set one. Rate-limit attempts; LinkPilot allows 5 per IP per minute per secret and logs every failure. - **Time-based expiry** — the secret dies after a set window even if never read. LinkPilot's signed-in form offers 1 hour, 24 hours or 7 days on every plan, with a custom date and time on Pro; the no-account generator sets 7 days by default. Covers the forgotten-in-inbox case that burn-after-read can't. - **Manual revoke** — the sender can kill an unread secret from the dashboard the moment something feels off. Cheap insurance for "sent it to the wrong Alex." ## Edge cases that separate good implementations ### The wrong person opens it first Burn-after-read doesn't stop the wrong viewer — it makes the misdelivery *visible*. The intended recipient hits a burned page, the audit trail shows one view you didn't expect, and you rotate the credential. Painful, but bounded: exactly one exposure, detected quickly. Compare that with a pasted-in-chat secret, where you'd never know. ### The screenshot problem One-time means one *reveal*, not one *copy*. The recipient can screenshot, copy, or retype the secret — nothing about the link prevents that, and vendors who imply otherwise are selling fiction. The honest framing: burn-after-read controls the delivery channel, not the recipient. Trust in the recipient is an input, not an output. ### Browser prefetch and speculative loading Some browsers and apps prefetch likely-clicked URLs. Because a well-built tool only burns on an explicit `POST`, prefetch behaves exactly like an unfurler: it can fetch the page shell, never the payload. ## When not to use a one-time link - **The value will be needed again.** Recoverability is the whole design goal of a password manager and the anti-goal of a one-time link. Use a vault item. - **Multiple recipients need it.** One link, one read. Fan-out means either creating one link per person (fine, auditable) or admitting you need shared access control instead. - **A machine is the consumer.** Services and CI should read from a secrets manager, not click links. If you want to watch the mechanism in action, create one with the [free secret link generator](/tools/free-secret-link-generator) — no account needed, encrypted in your browser, gone after the first reveal. ## Related reading - [Secure password sharing: 5 methods compared](/secure-password-sharing) - [Best OneTimeSecret alternatives](/blog/best-onetimesecret-alternatives) - [OneTimeSecret vs Privnote vs Password Pusher](/blog/onetimesecret-vs-privnote-vs-password-pusher) - [Expiring links: the secret is destroyed, not just redirected](/blog/expiring-links-security) - [Free secret link generator](/tools/free-secret-link-generator) Q: What happens if two people open the link at the same time? A: A correctly implemented one-time link performs the read and the mark-consumed in a single atomic database operation, so exactly one viewer wins. The other sees a 'burned' status. Without that atomicity, both can read the secret — a classic TOCTOU bug. Q: Does a link preview burn the secret? A: It shouldn't. Servers should only burn on an explicit reveal action (POST), not on the metadata fetch (GET) that chat and email clients use to render previews. LinkPilot's GET endpoint returns only status and whether a passphrase is required. Q: Why do burned links return HTTP 410 instead of 404? A: 410 Gone means the resource existed and is intentionally, permanently unavailable — which is exactly the semantics of a burned secret. It tells clients and caches not to expect the content to return, and it's honest: the link was real, and it's spent. Q: Can I recover a burned secret? A: No — that's the point. In LinkPilot the stored ciphertext is overwritten the moment the secret burns, expires, or is revoked, so there is nothing to restore. If you need recoverability, use a password manager and share a vault item instead. Q: Can the server read a one-time secret? A: Not in LinkPilot. The secret is encrypted in your browser with AES-GCM-256 before it is sent; the server stores only the ciphertext, and the decryption key travels in the URL fragment after #k=, which browsers never send to a server. A reveal returns the ciphertext and your browser decrypts it. Anyone holding the full link holds the key, which is why expiry and burn-after-read still matter. Q: Is it safe to send a one-time link over email? A: Reasonably, if the link expires and carries a passphrase sent through a different channel. Email is scanned, forwarded, and retained, so assume the URL itself may be seen — the passphrase and short expiry are what keep a seen URL from becoming a leaked secret. ### Expiring Links: The Secret Is Destroyed, Not Just Redirected — https://uselinkpilot.com/blog/expiring-links-security Published: 2026-05-26 · Updated: 2026-10-04 · By W. Miller An expiring secret link destroys the secret at the deadline; a dead shortener link only stops redirecting. How to pick a window, and the edge cases. An expiring secret link destroys the secret at the deadline: in LinkPilot the stored ciphertext is overwritten, so there is nothing left to redeem. A link shortener that starts returning 410 has only stopped the redirect. Every link carrying a secret should have an expiry, because without one your "one-time" guarantee silently weakens with every day the link sits unread. This post covers what expiry actually protects, how to pick a window you can defend, the edge cases that bite in practice, and the situations where expiring links are the wrong tool entirely. ## What expiry actually buys you Expiry caps the leakage window. A link that worked for five minutes is worth far less to an attacker than one that worked for a week — even if both were "one-time" links. Think about where a secret-bearing URL ends up after you hit send: the recipient's inbox, their email provider's storage, possibly a forwarded copy, chat history synced to a phone, a browser history entry. You can't control any of those copies. What you *can* control is how long any of them remains redeemable. A one-hour expiry means that every stray copy of that URL becomes worthless sixty minutes after creation, no matter where it landed. Expiry also handles a real human failure mode that burn-after-read cannot: **the recipient never opens the link.** Burn-after-read only fires on a read. An unread link with no expiry sits in an inbox indefinitely — still live, still searchable, still one forward away from the wrong person. ## Expiry and burn-after-read cover different failures These two controls get conflated constantly. They're orthogonal, and the strongest setup uses both: <table> <thead> <tr><th>Failure mode</th><th>Burn-after-read catches it?</th><th>Expiry catches it?</th></tr> </thead> <tbody> <tr><td>Recipient reads it, link lingers in inbox afterwards</td><td>Yes — already dead</td><td>Yes, eventually</td></tr> <tr><td>Recipient never opens it</td><td>No — stays live forever</td><td>Yes</td></tr> <tr><td>Wrong person opens it first</td><td>Partially — burns, and the audit trail shows it</td><td>No</td></tr> <tr><td>URL leaks weeks later from an email export</td><td>Only if it was read</td><td>Yes — long dead</td></tr> </tbody> </table> Note the "wrong person" row: neither control *prevents* that read — that's what a passphrase delivered out-of-band is for. Expiry bounds time, burn bounds reads, the passphrase bounds *who*. Three separate dials. ## Choosing a window A working rule of thumb, by scenario: <table> <thead> <tr><th>Scenario</th><th>Window</th><th>Why</th></tr> </thead> <tbody> <tr><td>Real-time hand-off (chat, call, screen-share)</td><td>1 hour (the shortest preset)</td><td>Recipient is present; burn-after-read closes the link the moment they read it</td></tr> <tr><td>Email to a known, active recipient</td><td>1 hour</td><td>Covers inbox lag without leaving an overnight window</td></tr> <tr><td>Scheduled hand-off (onboarding tomorrow at 10am)</td><td>24 hours</td><td>Survives schedule slips; still dead by the day after</td></tr> <tr><td>Recipient in a distant timezone</td><td>24–48 hours</td><td>Their working day may not overlap yours at all</td></tr> <tr><td>Anything needing > 7 days</td><td>Stop</td><td>The link is the wrong primitive — use a vault</td></tr> </tbody> </table> The pattern behind the table: set the window to *the expected hand-off time plus one reasonable delay*, not "long enough that I never have to think about it again." Convenience-driven expiry windows converge on infinity. ## A timed hand-off, step by step A new engineer starts tomorrow at 10:00. You need to hand them the production read-only database password. 1. **09:55** — create the secret link from your LinkPilot account with burn-after-read on, a passphrase, and a custom expiry at 11:00. The clock-time expiry and the passphrase are both Pro features; the signed-in presets are 1 hour, 24 hours or 7 days, and the no-account generator sets 7 days. 2. **09:56** — send the link by email. 3. **09:58** — send the passphrase by SMS or a Slack DM — a different channel than the link, so one leaked channel isn't enough. 4. **10:05** — recipient opens the link, enters the passphrase, reads the password once. The link burns. 5. **10:30** — you check the audit timeline. One view, correct time, plausible location. Done. 6. **If unread by 10:30** — revoke, ping them, and re-share live. Don't just wait for expiry; an unread live link is an open window. The window is short enough that a leaked email is worthless an hour later. The passphrase covers interception of the link inside that hour. The burn covers re-reads. Each control catches what the others miss. ## Edge cases worth knowing ### Email scanners don't consume the clock — or the secret Corporate email security tools fetch URLs the moment a message arrives. A well-built secret link treats those fetches as metadata requests: LinkPilot's reveal endpoint returns only status on a `GET`, and a view is recorded only on an explicit `POST` reveal. So a scanner hitting your link at 09:56 neither burns it nor tells the scanner anything useful. What scanners *can't* be prevented from doing is observing that a URL was sent — another reason the passphrase goes in a different channel. ### The recipient at minute 59 Expiry is enforced at reveal time, not by a background sweep you have to hope ran. In LinkPilot, an expired secret flips to `expired` status on the next access and the payload is redacted in the same write. A reveal that starts before the deadline and completes after it resolves cleanly one way or the other — there is no half-expired state. ### Timezone math "Expires in 24 hours" is unambiguous; "expires tomorrow evening" is not. Set windows as durations from now, and when you tell the recipient, give them the deadline in *their* timezone. A surprising number of "the link was dead when I opened it" complaints are timezone arithmetic. ## The compliance angle Expiry is also the practical implementation of two principles that show up in most modern privacy regimes: data minimization and storage limitation (in the GDPR, Articles 5(1)(c) and 5(1)(e)). If you must transmit personal data — an ID document, a customer record, an access credential tied to a person — a link that provably stops existing after a bounded window is a much easier story to tell an auditor than "it's somewhere in the email system." An audit trail showing creation, view, and expiry events for each share turns your retention claim into evidence rather than assertion. None of this makes a tool "GDPR compliant" by itself — compliance is a property of your whole process — but bounded lifetimes and event logs are the raw material. ## What expiry doesn't help with Expiry is not a substitute for: - **Rotation.** If the secret itself is compromised, expiry on the *link* doesn't invalidate the *credential*. Rotate at the source system. Expiry limits how long the delivery vehicle is hot — it says nothing about the payload once delivered. - **Passphrase protection.** Expiry bounds the time; the passphrase bounds the access. They're orthogonal, and cheap to combine. - **Audit logging.** Expiry tells you nothing about who saw the secret or when. Use per-link audit events for that — LinkPilot records created, viewed, failed-passphrase, burned, expired, and revoked events with timestamps and hashed IPs. ## The "I'll extend it" anti-pattern Tempting and almost always wrong. The recipient agreed to a window. Silently extending breaks the trust model — they assumed the link was dead and may have treated the secret accordingly, or stopped guarding the inbox it sits in. The clean pattern: revoke the old link, issue a new one with a new expiry, and tell the recipient. The audit trail stays truthful — one link, one window, one outcome per share. This is why LinkPilot lets you *shorten* an active window or revoke instantly, but deliberately has no "extend" button. ## When expiring links are the wrong tool An honest boundary list: - **Recurring access.** If someone will need the value next week too, put it in a password manager and share the vault item. Re-sending links on a schedule is a vault with extra steps and worse guarantees. - **Machine consumers.** CI pipelines and services should pull from a secrets manager (or the platform's native secret store), not fetch one-time URLs. - **Broad distribution.** A link that fifteen people need is not a secret hand-off; it's access control, and it belongs in a system that has some. Expiring links shine at exactly one job: moving a sensitive value from one person to another, once, with a bounded blast radius. ## Related reading - [How one-time secret links work](/blog/how-one-time-secret-links-work) - [Secure password sharing: 5 methods compared](/secure-password-sharing) - [Why URLs leak sensitive information](/blog/why-urls-leak-sensitive-information) - [Free secret link generator](/tools/free-secret-link-generator) Q: Isn't burn-after-read enough? A: Burn-after-read handles the read. Expiry handles the never-read case — links that get forgotten in inboxes, lost in long Slack threads, or that a recipient simply ignores. Use both; they cover different failure modes. Q: What's a sensible default expiry? A: For password and token hand-offs, 1 hour is a good default. For scheduled hand-offs like tomorrow-morning onboarding, 24 hours. For anything longer than 7 days, ask whether a link is the right primitive at all — a vault entry usually is. Q: Can I extend an active expiry? A: You shouldn't, and LinkPilot intentionally doesn't support it. The recipient is relying on the original window; silently extending breaks that contract. You can shorten the window or revoke immediately — if you need more time, revoke and send a fresh link. Q: Does an expired link leak anything? A: Not in a well-built tool. In LinkPilot, an expired secret flips to expired status on the next access and the stored payload is overwritten in the same write. Visitors see a status page, never content. Q: What expiry range does LinkPilot support? A: 1 hour, 24 hours or 7 days on every signed-in plan, and a custom date and time on Pro. The no-account tool defaults to 7 days. Any window can be combined with burn-after-read and with manual revocation from the dashboard. ### Client-Side Encryption for Secret Sharing — https://uselinkpilot.com/blog/client-side-encryption-for-secret-sharing Published: 2026-05-26 · Updated: 2026-07-14 · By W. Miller When client-side encryption matters for secret links, what guarantees it actually provides, and the trade-offs to be honest about. Client-side encryption sounds like a silver bullet for secret sharing. It isn't — it's a specific trade-off that protects against a specific threat, and it charges you real capabilities in exchange. This guide walks through what browser-side encryption actually guarantees, where it quietly breaks down, how it compares to the server-side model LinkPilot uses, and how to choose between the two without marketing fog. ## What client-side encryption actually does In a client-side encrypted (often called end-to-end encrypted, or E2EE) secret tool, the workflow looks like this: 1. The browser generates a symmetric key — typically a 256-bit AES-GCM key via the Web Crypto API (`crypto.subtle.generateKey`). 2. The payload is encrypted in the browser with that key. 3. Only the ciphertext is sent to the server, which stores it under a random slug. 4. The key is appended to the URL as a fragment (`#key=…`). Per RFC 3986, browsers never send the fragment portion of a URL in HTTP requests, so the key does not cross the wire to the server. 5. The recipient's browser reads the fragment, fetches the ciphertext, and decrypts locally. The server only ever sees ciphertext. Even a malicious server operator can't read the secret — provided every other link in the chain holds. ### Anatomy of an E2EE secret URL ``` https://example.com/s/x7Kd93hF2a#key=4fT9wLm2...Qz1 └──────── sent to the server ───┘└── browser-only ──┘ ``` Everything before the `#` travels in the HTTP request and can appear in server logs. The fragment is processed only by the recipient's browser. That one character is doing all of the security work — which is elegant, and also the root of most of the failure modes below. ## What it doesn't do - **It doesn't protect against malicious JavaScript.** The encryption code runs in the browser, and the browser got that code from the server. If the server delivers compromised JS — because the operator turned malicious, was compelled, or was hacked — the secret can be exfiltrated before or after encryption. This is the fundamental limit of browser-based E2EE. - **It doesn't protect against browser extensions.** Extensions with page access see the plaintext after decryption, and can read the URL fragment directly. - **It doesn't make URL leakage harmless.** The fragment is part of the URL. If the recipient pastes the full URL into chat, forwards the email, or has browser history sync enabled, the key travels with it. An E2EE link with a leaked URL is a fully readable secret. - **It doesn't audit, scan, or preview.** Because the server can't read the payload, it can't help with content filtering, malware scanning, data-loss prevention, or meaningful admin visibility. ### The code-delivery problem, spelled out The subtle point worth sitting with: browser E2EE means trusting the same server you supposedly don't trust to deliver honest JavaScript on every single page load. A native app is installed once, signed, and versioned; a web page is re-fetched every visit. Subresource integrity and published source code narrow the gap but don't close it. So the honest reading of "we can't read your secrets" is: "we can't read your secrets *passively*." Turning a passive capability into an active attack that ships modified code is still a meaningful upgrade — active attacks are riskier, targeted, and potentially detectable — but it is not the same as "impossible," and vendors who imply otherwise are overselling. ## Server-side encryption with hashed passphrases The pattern LinkPilot uses, documented in detail on the [Security Architecture](/security-architecture) page: - **TLS in transit** for all traffic between the recipient, the edge, and the database. - **Encryption at rest** — payloads live in a dedicated `secret_links` table, logically separated from analytics data, on a managed Postgres instance with disk-level encryption. - **Passphrases hashed client-side** with SHA-256 before transport, then compared by hash on the server. The raw passphrase never reaches the database or logs. - **Destructive burn** — when a secret is burned, expires, or is revoked, the stored payload is overwritten with `[REDACTED]` and later reveal attempts get HTTP 410. There is no restore. - **Brute-force resistance** — passphrase attempts are rate-limited to 5 per IP per minute per secret, and every failed attempt lands in the audit log with a hashed IP. The server *can* read an active secret's payload — that's what lets it enforce atomic burn-after-read, feed the audit timeline, and serve a clean reveal flow. It's also exactly the property E2EE removes. Neither is free. ## Trade-off summary <table> <thead> <tr><th>Concern</th><th>Client-side E2EE</th><th>Server-side + hashed passphrase</th></tr> </thead> <tbody> <tr><td>Malicious server operator (passive)</td><td>Mitigated</td><td>Trust required</td></tr> <tr><td>Malicious server operator (serves bad JS)</td><td>Not mitigated</td><td>Not mitigated</td></tr> <tr><td>Compromised JS / supply chain</td><td>Not mitigated</td><td>Not mitigated</td></tr> <tr><td>External attacker with a DB dump</td><td>Mitigated (ciphertext only)</td><td>Mitigated (encryption at rest; burned payloads already redacted)</td></tr> <tr><td>Leaked URL, no passphrase</td><td>Secret fully readable — key is in the fragment</td><td>Secret readable until burn/expiry; passphrase closes this</td></tr> <tr><td>Server-side audit log</td><td>Access events only</td><td>Full lifecycle: created, viewed, failed passphrase, burned, expired, revoked</td></tr> <tr><td>Recipient UX</td><td>Slightly worse</td><td>Native</td></tr> <tr><td>Admin / team visibility</td><td>None</td><td>Configurable</td></tr> </tbody> </table> Neither model is "more secure" in the abstract. They defend different threats with different costs. ## Matching the model to the threat: three scenarios **1. Sending a contractor a database password.** Threat: the secret lingering in email or chat, or a stray forward. Both models handle this well; the deciding factors are usability, expiry controls, and the audit trail. Server-side with a short expiry, burn-after-read, and an out-of-band passphrase is the pragmatic pick. **2. A journalist receiving material from a source.** Threat model includes the platform operator being compelled to disclose. Here the operator *is* part of the threat model, so E2EE (or better, purpose- built tools like SecureDrop) is the right call, accepting the usability cost. **3. An engineering team doing routine credential hand-offs.** Threat: sprawl, forgotten links, no record of who saw what. The features that matter — audit timelines, revocation, team workspaces, expiry policy — all live server-side. E2EE would trade away the controls this team actually needs. ## How to choose Pick **client-side E2EE** when: - You don't trust the server operator — including yourself running on cloud infrastructure you can't fully verify. - Regulatory or contractual rules require that the provider be technically unable to read the content. - The trade-off of zero server-side features is acceptable. Pick **server-side encryption with hashed passphrases** when: - You need team workspaces, audit logs, or admin visibility. - You want the server to defend against link unfurlers, passphrase brute-force, and abuse. - Your threat model is "external attacker" and "secret left behind in chat," not "compromised operator." ## When not to use either Some secrets shouldn't travel through *any* sharing link. Long-lived root credentials, production signing keys, and bulk data exports belong in a secrets manager or KMS with access control, not in a URL of any kind. And if the recipient needs the value repeatedly, a password manager vault item beats re-sending links — one-time delivery is for hand-offs, not storage. ## Honest positioning *Update, 29 September 2026: when this article was published, LinkPilot did not claim end-to-end encryption, and the section below said so. It does now. Text payloads are encrypted in the browser with AES-GCM-256 and the key is placed in the URL fragment, so our server only ever holds ciphertext — the model this article describes. Everything above about what that model does not solve applies to us too: malicious JavaScript, browser extensions, URL leakage, and the loss of server-side preview or scanning. Attached files are encrypted the same way, though a file's name, size and type remain visible to us as metadata. Secrets created before that date are stored as plaintext until they expire. The [Security Architecture](/security-architecture) page states the current model.* The advice the article closes on has not changed. Don't pick a tool based on which one claims more. Pick based on what you're actually defending against — and verify that the claims on the tin match the architecture underneath. That test applies to this claim of ours as much as to anyone else's. ## Related reading - [How one-time secret links work](/blog/how-one-time-secret-links-work) - [LinkPilot vs PrivateBin](/linkpilot-vs-privatebin) - [Secret links vs password managers](/blog/secret-links-vs-password-managers) - [Why URLs leak sensitive information](/blog/why-urls-leak-sensitive-information) Q: Does LinkPilot use client-side encryption? A: Yes, since 29 September 2026. Text payloads are encrypted in the browser with AES-GCM-256 and the 256-bit key is placed in the URL fragment, which browsers never transmit, so the server only ever holds ciphertext. Passphrases are additionally hashed client-side with SHA-256 and stretched into the key with PBKDF2 and HKDF. File attachments are encrypted the same way, with a key derived from the same content key. Two exceptions remain: a file's name, size and type are stored as plaintext metadata even though its contents are not, and secrets created before that date are stored as plaintext until they expire. Q: What's the practical difference between the two models? A: With server-side encryption, the server can read the payload to deliver it. With client-side E2EE, the server only ever sees ciphertext. Both protect against external attackers; they differ on whether you have to trust the server operator. Q: Is client-side encryption the same as zero-knowledge? A: Vendors use 'zero-knowledge' loosely. The strict meaning is that the server never holds enough material to decrypt your data. Verify how the key is generated and transported, whether it ever appears outside the URL fragment, and whether the client code is published — not just whether the label appears on the pricing page. Q: Does the URL fragment really stay off the server? A: Yes — per RFC 3986, browsers do not include the fragment (#...) portion of a URL in HTTP requests. But the fragment still lives in the recipient's browser history, bookmarks, sync services, and anywhere someone pastes the full URL, so the key can still leak client-side. Q: Is E2EE always worth the complexity? A: No. It adds friction — key in URL fragment, no server-side preview, no content scanning, weaker admin visibility — that many teams don't need. Pick based on the threat you're actually defending against, not the label. ### The 30-Second Redirect Audit Every Marketer Should Run Monthly — https://uselinkpilot.com/blog/redirect-chain-audit-guide Published: 2026-05-25 · By LinkPilot Team Redirect chains cost you speed, conversions, and attribution data. Here's what 301/302/307/308 mean, why chains hurt, and a copy-paste monthly audit checklist. Every redirect hop between a user's click and your landing page costs you something. Time. Conversions. Attribution data. In some cases, search rankings. And yet most marketing teams have no idea how many redirects are hiding inside their campaigns, email newsletters, and paid ad links. This guide explains what redirects are, why different types matter, what redirect chains actually cost you, and how to run a fast monthly audit to catch problems before they hurt your campaigns. ## What Is a Redirect? A redirect is an instruction that sends a browser from one URL to another. When you click a link, your browser sends a request to the server. A redirect means the server responds with "don't load this page — go to this other URL instead," and your browser follows the instruction.<sup>[1]</sup> This happens invisibly and almost instantly in most cases. The problem is that "almost instantly" adds up — and not all redirects are created equal. ## The Four Redirect Types Marketers Need to Know HTTP defines several redirect status codes.<sup>[1]</sup> Four of them come up constantly in marketing work. ### 301 — Permanent Redirect A 301 tells browsers and search engines: "This page has moved permanently. Update your records." Search engines will transfer most of the original page's ranking signals to the new destination. Browsers may cache a 301, meaning repeat visitors could go directly to the destination without ever pinging your server again. **Marketing implication:** Good for permanently retired URLs (an old product page pointing to its replacement). Not ideal for short links, because if a browser caches the 301, you lose the ability to change the destination later without a cache-busting workaround — and some click tracking may be missed on cached requests. ### 302 — Temporary Redirect A 302 tells browsers and search engines: "Go to this other URL for now, but don't update your records — this might change." Browsers won't cache 302s the same way, so every visit passes through the redirect server.<sup>[1]</sup> **Marketing implication:** The default choice for link shorteners and campaign links, because it preserves the ability to update the destination and ensures every click is logged. If you're using a link management platform, it almost certainly uses 302s. ### 307 — Temporary Redirect with Method Preservation A 307 is like a 302, but it explicitly preserves the HTTP method of the original request (GET, POST, etc.). This mostly matters for developers building forms or API integrations — not for typical marketing links.<sup>[1]</sup> ### 308 — Permanent Redirect with Method Preservation A 308 is the permanent version of 307 — like a 301 that also preserves the request method. Again, primarily a developer concern.<sup>[1]</sup> **The practical summary for most marketers:** 302 is what you want for campaign links. 301 is for permanent URL migrations. If you're seeing 307s or 308s in your marketing links, something unusual is happening worth investigating. ## What Is a Redirect Chain, and Why Is It a Problem? A redirect chain occurs when a URL redirects to another URL that itself redirects — creating a sequence of hops before the browser reaches the final destination. A simple example: ``` Your short link (hop 1) → Tracking/affiliate URL (hop 2) → Old campaign URL (hop 3) → Final landing page ``` This is three hops. Here's what each one costs you: ### Latency Every redirect hop adds a round-trip network request. Each hop typically adds **100–300 milliseconds** of load time.<sup>[2]</sup> On a fast desktop connection, three hops might add 300ms — noticeable but tolerable. On mobile on a weak signal, it can add a full second or more. Google has made page speed a ranking factor for mobile search results, and Core Web Vitals — particularly Largest Contentful Paint (LCP) — are directly affected by redirect delays.<sup>[3]</sup> ### Broken UTM Attribution When a UTM-tagged URL passes through a redirect chain, there's a real risk that UTM parameters get dropped at one of the intermediate hops.<sup>[4]</sup> This causes conversions to appear as "direct" traffic in your analytics, making it impossible to attribute them back to the campaign that actually drove them. This is particularly common when: - A short link redirects to a URL that already has different UTM parameters - An affiliate network uses a redirect that strips query strings - A CMS auto-redirects non-trailing-slash URLs (e.g., `/page` → `/page/`) and doesn't forward parameters ### Broken Link Previews As covered in [our Open Graph guide](/blog/fix-open-graph-link-previews), social media scrapers — especially LinkedIn's — often don't follow redirect chains reliably. A link with two or more hops may produce no preview, or a preview from the wrong page. ### Redirect Loops The worst-case scenario: URL A redirects to URL B, which redirects back to URL A. Browsers will eventually give up and show an error.<sup>[1]</sup> These are usually caused by misconfigured CMS settings, conflicting redirect rules, or incorrect HTTPS/HTTP enforcement. ## How to Audit Your Redirects: The Monthly Checklist Use the Redirect Checker tool below to inspect any URL — paste it in and see the full chain, each status code, and the final destination. [[tool:redirect-checker]] ### What to audit each month **1. Your most-used campaign short links.** Pull your top 10 most-clicked short links from the past 30 days. Check each one for chain length (more than 1 hop is worth investigating) and correct final destination (pages get moved without redirect updates more often than you'd think). **2. Links in your current email campaigns.** Email links are often the worst offenders for redirect chains. A typical chain might look like: ESP click-tracking URL → your short link → destination. That's already two hops before the page even loads. Add a CMS redirect and you're at three. **3. Paid ad destination URLs.** Google Ads, Meta Ads, and LinkedIn Ads all have URL policies around redirect behavior. Google Ads specifically prohibits redirect chains that obscure the final destination domain.<sup>[5]</sup> Beyond policy compliance, chains in paid ad URLs directly inflate your cost-per-click because slower landing pages reduce Quality Score.<sup>[5]</sup> **4. Links in high-traffic blog posts.** If you have articles linking out to partner pages, product pages, or resources, those destination pages may have moved since you published. A quick monthly sweep catches 404s and accidental chains early. **5. Any link that recently "stopped working" but technically still redirects.** Sometimes a redirect chain is technically functional but routes to an outdated page. The browser reaches a destination — it's just the wrong one. These are easy to miss without an explicit audit. ## How to Fix the Problems You Find ### Too many hops The fix is usually straightforward: update the original short link to point directly to the final destination, bypassing intermediate URLs. Most link management platforms let you edit the destination of any existing short link without changing the link itself — this is one of the key advantages of using managed short links over hard-coded URLs. ### Wrong redirect type (301 where you want 302) If you set a redirect to 301 and later need to change the destination, the browser cache becomes a problem. The only reliable fix is to use a link management platform that issues 302s by default, or to wait out the cache TTL and update the destination at the CDN or server level. ### UTM parameters being dropped First, verify the problem: set up a test click from the link and check your analytics in real time to see what source/medium/campaign is recorded. If the UTMs are missing, trace the chain manually to identify which hop strips them. Fixes include: - Enabling parameter forwarding on your short link platform (this appends incoming query strings to the destination URL automatically) - Rebuilding the destination URL to include the UTM parameters directly, removing the dependency on pass-through - Removing the intermediate hop that strips the parameters ### Redirect loops These need to be diagnosed at the server or CMS level. Common causes include: - A WordPress plugin (often SSL enforcement or caching plugins) creating a circular rule - An `.htaccess` file with conflicting rewrite rules - HTTPS-to-HTTP and HTTP-to-HTTPS rules set simultaneously on different systems - A CDN and origin server both trying to enforce redirects in conflicting directions The Redirect Checker will identify loops by showing a circular reference. Once you know which hop creates the circle, isolate and remove the conflicting rule. ## A Note on Short Links and Redirect Performance Well-built link management platforms optimize redirect performance by caching destination lookups at the edge — meaning the redirect happens from a server close to the user rather than routing all the way to a central origin server. This can reduce redirect latency to under **20 milliseconds** even for a global audience. If you're using a self-hosted or poorly optimized redirect setup, the single hop from a short link to a destination can take 400–800ms — more than a well-built multi-hop chain on optimized infrastructure. Infrastructure quality matters more than hop count in those cases, but minimizing hops remains best practice regardless. ## Copy-Paste Monthly Audit Template ``` REDIRECT AUDIT — [Month, Year] Date completed: ___________ Auditor: ___________ URLs checked: [ ] Top 10 short links (by clicks) [ ] All links in current email campaign [ ] All paid ad destination URLs [ ] Top 5 blog posts (external links) [ ] Any links flagged by team in past month For each URL, note: - Final destination correct? (Y/N) - Number of redirect hops: ___ - Redirect types (301/302/other): ___ - UTM parameters intact at destination? (Y/N) - Any loops or errors? (Y/N) Actions logged: [ ] Updated destination on: ___________ [ ] Fixed UTM passthrough on: ___________ [ ] Resolved loop on: ___________ [ ] Flagged for dev: ___________ Next audit scheduled: ___________ ``` ## References **[1]** Fielding, R., Nottingham, M., & Reschke, J. (2022). *RFC 9110: HTTP Semantics*, §15.4 (Redirection 3xx). IETF. <https://www.rfc-editor.org/rfc/rfc9110#section-15.4> **[2]** Google Developers. (2024). *Avoid multiple page redirects*. web.dev / Chrome for Developers. <https://developer.chrome.com/docs/lighthouse/performance/redirects/> **[3]** Google Search Central. (2024). *Understanding Core Web Vitals and Google search results*. <https://developers.google.com/search/docs/appearance/core-web-vitals> **[4]** Google LLC. (2024). *Collect campaign data with custom URLs*. Google Analytics Help. <https://support.google.com/analytics/answer/1033863> **[5]** Google LLC. (2024). *Google Ads destination requirements policy*. <https://support.google.com/adspolicy/answer/6368661> --- *Last updated: May 2026. See also: [Link Shortening Glossary](/glossary) — Redirect, 301/302/307/308, Redirect chain, Redirect loop, Parameter forwarding, UTM parameters.* Q: What's the difference between a 301 and 302 redirect? A: A 301 is permanent — search engines transfer ranking signals to the new URL and browsers may cache the redirect. A 302 is temporary — every visit re-checks the redirect server, so you keep the ability to change the destination and log every click. Most link shorteners use 302s for that reason. Q: How much does a redirect chain slow down a page? A: Each hop typically adds 100–300 milliseconds on a fast connection. On weak mobile signal, three hops can add a full second. Google's Core Web Vitals (particularly LCP) are directly affected, and Google Ads Quality Score penalizes slow landing pages. Q: Why are my UTM parameters disappearing? A: They're almost always being stripped at an intermediate redirect hop — an affiliate network, a CMS trailing-slash redirect, or a destination URL that already has its own UTMs. Trace the chain hop by hop with a redirect checker, then enable parameter forwarding or rebuild the URL to include UTMs at the final destination. Q: How often should I audit my redirects? A: Monthly for top campaign short links, current email campaigns, and paid ad destinations. Quarterly for evergreen blog content. Always immediately after migrating a CMS or changing redirect rules. ### Link Trust Scoring: How to Audit Outbound Links Before You Share Them — https://uselinkpilot.com/blog/link-trust-scoring-guide Published: 2026-05-25 · By LinkPilot Team Your brand's reputation travels with every outbound link. The six trust signals that matter and how to build an audit habit for newsletters and affiliates. Your brand's reputation travels with every link you share. A phishing URL in a company newsletter. A malware-distributing link in a Slack post. An expired domain in an affiliate stack that was quietly bought by a scammer. These aren't hypothetical risks — they're documented incidents that have damaged real organizations' reputations and eroded reader trust overnight. Link trust scoring is the practice of systematically evaluating whether a URL is safe, credible, and appropriate to share before it goes out under your name. This guide explains what makes a link trustworthy, how to assess it, why your outbound link hygiene matters more than ever in an era of AI-assisted content discovery, and how to build an audit habit that protects your brand. ## Why Outbound Link Trust Matters More Than Ever For a long time, link safety was thought of as a consumer problem — something individuals needed to watch out for, not something brands needed to actively manage. That has changed significantly for three reasons. **AI search surfaces your links directly.** When AI assistants like Google's AI Overviews, Perplexity, or ChatGPT cite your content, they may also surface or follow the outbound links within it. A low-quality or malicious outbound link in a piece you published can now influence AI-generated answers — and by extension, the trust people place in those answers. Content that cites authoritative, trustworthy sources ranks and surfaces better in AI-assisted search.<sup>[1]</sup> **Phishing campaigns routinely exploit trusted brands.** Attackers frequently use short links, compromised redirect chains, and lookalike domains to make malicious URLs appear to originate from legitimate organizations.<sup>[2]</sup> If your brand's link infrastructure is compromised — or if you share a malicious link without knowing it — you become an unwitting vector for the attack. **Newsletters and affiliate stacks accumulate link rot and domain changes.** A destination you've linked to for two years may have been sold, redirected to adult content, or converted into a spam farm. Older links in evergreen content are especially vulnerable.<sup>[3]</sup> ## What "Link Trust" Actually Measures Link trust isn't a single number — it's a composite of several independent signals. Understanding each one helps you diagnose problems faster. ### 1. HTTPS and TLS Certificate Validity The most basic trust signal is whether a link uses HTTPS. HTTPS means the connection between your browser and the server is encrypted using TLS, protecting the data in transit from interception.<sup>[4]</sup> But HTTPS alone isn't sufficient. A phishing site can obtain a free TLS certificate from a certificate authority like Let's Encrypt in minutes — and many do. What matters beyond the presence of HTTPS is whether the certificate is: - **Issued to the correct domain** (not a lookalike) - **Currently valid** (not expired) - **Issued by a recognized certificate authority** (not self-signed) - **Not revoked** A link that redirects from HTTPS to HTTP at any point in its chain is also a red flag — it means traffic is unencrypted for part of the journey.<sup>[4]</sup> ### 2. Domain Age and Registration History Newly registered domains are disproportionately used for fraud. Research from cybersecurity firm Palo Alto Networks found that newly registered domains are **10 times more likely** to be malicious than established ones.<sup>[5]</sup> Domain age can be checked via WHOIS records, though many registrars now offer privacy protection that masks registration dates. A domain registered within the last 60–90 days with no established web presence is worth treating with caution, especially if the URL was sent to you unsolicited. Domain history matters too. A domain that previously hosted legitimate content but was recently sold or allowed to expire may have been re-registered by an actor who wants to exploit its existing backlinks and search rankings. ### 3. Blocklist Status Major cybersecurity organizations and browser vendors maintain databases of known malicious domains and URLs. Google Safe Browsing, for example, scans billions of URLs and maintains a continuously updated list of phishing sites, malware distributors, and social engineering pages.<sup>[6]</sup> Firefox, Chrome, and Safari all query this list before loading a page. Being able to check a link against major blocklists before sharing it — rather than after a user clicks it — is the core value of link scanning tools. Relevant blocklists include: - **Google Safe Browsing**<sup>[6]</sup> - **Spamhaus** — widely used for email and domain reputation - **Cisco Talos** — threat intelligence for domains and IPs - **Phishtank** — community-curated phishing database - **SURBL** — spam URI blocklist used by mail filters A link appearing on any of these lists will be flagged or blocked by browsers, email clients, and security tools — often causing your newsletter to be marked as spam or your emails to be quarantined before they reach readers. ### 4. Redirect Transparency A trustworthy link goes where it says it goes. A link that claims to go to `trusted-news-source.com` but actually routes through three hops to a different domain is not transparent — and reduced transparency is a hallmark of malicious links.<sup>[2]</sup> [Redirect chains](/blog/redirect-chain-audit-guide) create opacity. Each hop obscures the true destination and gives a bad actor an opportunity to insert a malicious step. Even if the original link was safe when you added it, a chain that runs through a third-party redirect service means you're trusting that service to remain safe in perpetuity. **Best practice:** Verify that the final destination of any link you share matches the domain you intend to reference. Don't trust the display text of a hyperlink — always check where the URL actually resolves. ### 5. Domain Reputation Score Beyond blocklists, several security and email deliverability vendors maintain reputation scores for domains based on signals like spam complaints, phishing reports, malware associations, WHOIS patterns, and traffic behavior. These scores are probabilistic — a domain can have a poor reputation score without being explicitly listed on a blocklist, because the signals aren't yet conclusive. Domain reputation is especially relevant for email marketers, because ESPs (email service providers) use reputation scoring to determine whether your newsletter's outbound links will trigger spam filters — even if the links themselves are safe. ### 6. IP Address Reputation The IP address hosting the destination server carries its own reputation. A server that hosts dozens of domains, many of which have been flagged for abuse, is a warning sign even if the specific domain you're linking to is clean.<sup>[7]</sup> IP address reputation data is used by enterprise security systems, email filters, and browser safe browsing implementations to assess risk at the network level. ## Check Any Link Right Now The Link Trust Score tool below evaluates a URL across the key signals described above — HTTPS validity, redirect transparency, blocklist status, domain age, and reputation — and returns a composite score along with a breakdown of any flags. [[tool:link-trust-score]] ## Where Outbound Link Risk Is Highest Not all links in your organization carry equal risk. These are the highest-priority places to audit. ### Email Newsletters Newsletter links are the most dangerous surface area for several reasons. First, they reach your entire subscriber list at once — a single malicious link can damage trust with thousands of readers simultaneously. Second, ESPs scan outbound links for reputation signals, so a low-trust link can cause your entire newsletter to land in spam. Third, newsletters are difficult to retract once sent. **Audit cadence:** Scan every outbound link in a newsletter before sending. This is non-negotiable for brands in regulated industries (finance, healthcare, legal) where a malicious link could also trigger compliance liability. ### Affiliate and Partner Link Stacks Affiliate links often route through multiple redirect layers — your short link, an affiliate network, a merchant redirect — and the final destination can change without notice if an affiliate relationship ends or a merchant updates their URL structure. Destination domains can also be sold or allowed to expire. **Audit cadence:** Monthly review of all active affiliate links, with automated monitoring for destination changes where possible. ### Evergreen Blog Content Blog posts written 2–5 years ago may contain dozens of outbound links to resources, studies, tools, and partner sites. Many of those destinations will have moved, expired, or changed ownership. A 2019 article linking to a now-defunct startup whose domain has been re-registered as a spam farm is a real and common problem. **Audit cadence:** Quarterly review for high-traffic evergreen pages. Use your link checker or a tool like Screaming Frog to identify 404s and redirect chains at scale, then manually review the riskiest destinations. ### Social Media Posts (Especially Those Using Short Links) Short links are convenient but opaque by design — they hide the final destination. Malicious actors exploit this to share harmful links that appear to come from legitimate short domains. Before sharing a short link in an official brand post, verify it resolves to the intended destination.<sup>[2]</sup> ### Slack, Teams, and Internal Communication Platforms Internal communications are often overlooked in link auditing. But employees click links in Slack and Teams with a high degree of trust, and attackers know this. Social engineering attacks frequently start with a "safe-looking" link sent through a compromised account or an impersonation of a vendor. ## Building a Practical Outbound Link Audit Habit The goal is not to manually investigate every link you ever share — that's unrealistic. The goal is a lightweight, repeatable system that catches the highest-risk scenarios. ### For one-person or small teams 1. **Before every newsletter send:** Paste each outbound link into the Link Trust Score tool. Flag anything with a score below threshold for a second review. 2. **Monthly:** Check your top 10 most-linked-to domains across all content. Have any been sold? Any HTTPS issues? Any new blocklist entries? 3. **When a link comes in from outside your organization:** Always check short links, unfamiliar domains, and links from new partners before sharing them internally or externally. ### For larger marketing or content teams 1. **Build link checking into the editorial workflow.** Require trust score verification for all external links before an article publishes. 2. **Automate monitoring for destination changes.** Several link management platforms support link health monitoring that alerts you when a destination goes down, changes significantly, or returns an error — extending this to reputation changes is the next logical step. 3. **Add link scanning to your email pre-send checklist.** Most ESPs don't automatically scan for malicious links — that responsibility sits with the sender. 4. **Log and review abuse reports.** If any of your links generate user complaints about unexpected destinations, investigate immediately and update or retire the link. ## What Good Links Look Like: A Trust Checklist | Signal | Trustworthy indicator | |---|---| | Protocol | HTTPS throughout — no HTTP hops in the chain | | TLS certificate | Valid, not expired, issued to the correct domain | | Certificate authority | Recognized CA (DigiCert, Sectigo, Let's Encrypt, etc.) | | Domain age | Established — not newly registered within 90 days | | Domain history | No history of abuse, spam, or malicious hosting | | Blocklist status | Not listed on Google Safe Browsing, Spamhaus, or Phishtank | | IP reputation | Clean — not hosted on infrastructure with abuse history | | Redirect chain | Transparent — resolves to the expected final domain | | Final destination | Matches the intended resource — not an unexpected domain | | WHOIS / registration | Registrar and registration info consistent with the organization | ## A Note on PII and Privacy in Link Auditing When you run a URL through a link trust tool, that tool typically makes requests to the destination URL and to reputation databases on your behalf. Be mindful that: - The destination server will log the request (including IP address) - Some reputation databases are commercial and may log queried URLs - For sensitive internal links (behind authentication), don't run them through external tools For internal links, rely on your own network's security tools rather than external scanning services. ## References **[1]** Google Search Central. (2024). *Creating helpful, reliable, people-first content*. <https://developers.google.com/search/docs/fundamentals/creating-helpful-content> **[2]** Anti-Phishing Working Group (APWG). (2024). *Phishing Activity Trends Report, Q4 2024*. <https://apwg.org/trendsreports/> **[3]** Pew Research Center. (2024). *When Online Content Disappears*. <https://www.pewresearch.org/data-labs/2024/05/17/when-online-content-disappears/> **[4]** Rescorla, E. (2018). *RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3*. IETF. <https://www.rfc-editor.org/rfc/rfc8446> **[5]** Palo Alto Networks Unit 42. (2019). *New Domains: Malicious Intent by Design*. <https://unit42.paloaltonetworks.com/new-domains-malicious-intent-by-design/> **[6]** Google LLC. (2024). *Safe Browsing APIs*. <https://developers.google.com/safe-browsing/v4> **[7]** Fielding, R., Nottingham, M., & Reschke, J. (2022). *RFC 9110: HTTP Semantics*. IETF. <https://www.rfc-editor.org/rfc/rfc9110> --- *Last updated: May 2026. See also: [Link Shortening Glossary](/glossary) — SSL/TLS/HTTPS, Phishing, Lookalike domain, Blocklist, Domain reputation, Safe browsing, Link scanning, PII/Personal data.* Q: What is a link trust score? A: A link trust score is a composite of independent safety signals — HTTPS and TLS certificate validity, domain age, blocklist status, redirect transparency, domain reputation, and IP reputation — combined into a single 0–100 rating that tells you whether a URL is safe to share. Q: Why does outbound link safety matter for my brand? A: AI search engines (Google AI Overviews, Perplexity, ChatGPT) increasingly surface and follow outbound links in the content they cite. Low-quality outbound links can hurt your rankings and AI visibility. Beyond SEO, a malicious link shared in your newsletter can mark your sender domain as spam and damage subscriber trust overnight. Q: How often should I audit outbound links? A: Before every newsletter send for active campaigns. Monthly for top short links and affiliate stacks. Quarterly for evergreen blog content (many destinations get sold, expire, or change ownership over multi-year horizons). Q: Are HTTPS links automatically safe? A: No. Phishing sites obtain free TLS certificates from Let's Encrypt in minutes. HTTPS confirms the connection is encrypted, but not that the destination is trustworthy. You still need to check the domain age, blocklist status, and reputation. ### Why Your Links Look Broken on LinkedIn (and How to Fix Open Graph Tags) — https://uselinkpilot.com/blog/fix-open-graph-link-previews Published: 2026-05-25 · By LinkPilot Team LinkedIn, Facebook and Slack link previews break for 8 common reasons — missing OG tags, wrong image size, caching, redirects. How to diagnose and fix each one. You spend an hour writing a LinkedIn post, paste in the link, and wait for the preview to appear. Nothing. Or worse — the wrong image shows up, the title is garbled, and the description is a random snippet of page text that makes no sense out of context. You're not alone. Broken link previews are one of the most common — and most fixable — problems in digital marketing. This guide walks through the eight most frequent causes, shows you exactly what to look for, and lets you test your own URL with the Open Graph Preview tool embedded below. ## What Are Open Graph Tags? When you share a URL on LinkedIn, Facebook, Slack, Twitter/X, iMessage, or almost any social platform, that platform doesn't just display the raw link. It fetches the page in the background, reads a set of hidden HTML tags called **Open Graph (OG) tags**, and uses them to build a rich preview card showing a title, description, and image. Open Graph was originally developed by Facebook and published as an open protocol in 2010.<sup>[1]</sup> It has since become the universal standard for link previews across nearly every platform. A typical set of OG tags in a page's HTML `<head>` looks like this: ```html <meta property="og:title" content="Your Page Title" /> <meta property="og:description" content="A short description of this page." /> <meta property="og:image" content="https://example.com/images/preview.jpg" /> <meta property="og:url" content="https://example.com/your-page/" /> <meta property="og:type" content="website" /> ``` When these tags are present, correct, and reachable, previews work beautifully. When any one of them is missing, wrong, or blocked, the preview breaks — sometimes silently. > **New to the terminology?** See the [Link Shortening Glossary](/glossary) for plain-English definitions of Open Graph tags, social previews, canonical URLs, and related concepts. ## Test Your URL Right Now Before diving into the eight causes, use the tool below to check any URL you're working with. It fetches your page the same way LinkedIn and Facebook do and shows you exactly what tags are present, what's missing, and what the preview will look like. [[tool:open-graph-preview]] ## The 8 Most Common Reasons Your Link Preview Is Broken ### 1. The OG Tags Are Missing Entirely The most common cause. Many websites — especially older ones, custom-built tools, and app pages — simply don't have Open Graph tags in their HTML. When a social platform can't find them, it improvises: it might pull the page `<title>`, grab the first paragraph of body text, or show no image at all. **What to look for:** View your page's source (right-click → View Page Source in most browsers) and search for `og:title`. If you find nothing, the tags aren't there. **How to fix it:** Add the five core tags listed above to your page's `<head>` section. If you're on WordPress, plugins like Yoast SEO or Rank Math handle this automatically. On most website builders (Squarespace, Webflow, Wix), there's a dedicated SEO or social sharing settings panel per page. ### 2. The OG Image Is Too Small Platforms enforce minimum image dimensions and will refuse to display images that fall below them. LinkedIn, for example, requires images to be at least **1200 × 627 pixels** for the large card format.<sup>[2]</sup> Facebook recommends the same dimensions and will downgrade to a small thumbnail — or no image — if yours is smaller. Common culprits: a company logo (usually square and small), a favicon, or a stock photo that was compressed down before uploading. **What to look for:** The preview tool will show you the resolved image and its dimensions. A correctly sized OG image for modern platforms is **1200 × 630 pixels** (a 1.91:1 aspect ratio). **How to fix it:** Create a dedicated social sharing image at 1200 × 630 pixels. This is different from your page's hero image — it's specifically designed to look good cropped into a horizontal card. Tools like Canva have pre-built templates at exactly this size. ### 3. The Platform Has Cached an Old Preview LinkedIn, Facebook, and other platforms aggressively cache link previews — sometimes for days or even weeks. This means that even after you fix your OG tags, the old (broken) preview keeps appearing because the platform hasn't re-fetched the page. This is one of the most frustrating scenarios because the fix is already deployed, but nothing seems to have changed. **How to fix it:** Each major platform provides a scraper or debugger tool that forces a re-fetch: - **LinkedIn:** Use the [LinkedIn Post Inspector](https://www.linkedin.com/post-inspector/) — paste your URL, click "Inspect," and it will scrape fresh data and clear the cache for that URL. - **Facebook / Meta:** Use the [Meta Sharing Debugger](https://developers.facebook.com/tools/debug/) — paste your URL and click "Scrape Again." - **Twitter/X:** Cache clears more frequently, but you can trigger a refresh by appending a harmless query parameter (e.g., `?v=2`) the first time, then removing it. Make cache-busting your first step after any OG tag change. ### 4. A Redirect Is Getting in the Way If your URL redirects to another URL before the final page loads, some platforms read the OG tags from the *intermediate* URL rather than the final destination — or fail to follow the redirect at all.<sup>[3]</sup> This is especially common with: - Short links (which redirect to a long destination URL) - Old URLs that 301-redirect to new ones - Links with tracking parameters that pass through a redirect layer - Affiliate links routed through multiple hops A [redirect chain](/blog/redirect-chain-audit-guide) — where URL A redirects to URL B which redirects to URL C — compounds the problem significantly. Each hop is another opportunity for the scraper to give up or read the wrong page. **How to fix it:** Use the shortest possible redirect path (ideally a single hop direct to the final page). Ensure the final destination page has correct OG tags. If you're using a link shortener, check whether your platform supports OG tag passthrough or custom social preview overrides — many link management platforms let you set OG data directly on the short link itself, bypassing whatever is on the destination page. ### 5. The OG Image Is Too Large (File Size) While dimensions matter, file size matters too. Facebook's official guidance recommends keeping OG images under **8MB**,<sup>[4]</sup> but in practice, images over **1–2MB** frequently cause timeouts when scrapers try to fetch them — especially on slower servers or shared hosting. A 4K screenshot, an uncompressed PNG exported from design software, or a raw photo from a camera can easily be 5–15MB despite having correct pixel dimensions. **How to fix it:** Compress your OG image before uploading. Tools like [Squoosh](https://squoosh.app/) (Google's free browser-based image compressor) or [TinyPNG](https://tinypng.com/) can reduce file size by 60–80% with no visible quality loss. Aim for under 500KB for fast, reliable loading on all platforms. ### 6. The Wrong MIME Type Is Being Served A MIME type is the label a server attaches to a file that tells the browser (or scraper) what kind of file it is. If your server sends an image with the wrong MIME type — for example, labeling a JPEG as `text/html` — scrapers will reject it and show no image, even if the file itself is perfectly valid.<sup>[5]</sup> This sounds obscure, but it happens more often than you'd expect, particularly with: - Images served from a CDN with misconfigured headers - Files uploaded without proper extensions (e.g., `preview` instead of `preview.jpg`) - Servers that default all unknown files to `application/octet-stream` **What to look for:** The Open Graph Preview tool will show you the content type returned for your OG image. It should be `image/jpeg`, `image/png`, `image/gif`, or `image/webp`. Anything else will cause problems on at least some platforms. **How to fix it:** If you control the server, configure it to serve images with the correct `Content-Type` header. If you're using a CMS or CDN, re-upload the image with the correct file extension and verify the served headers using your browser's developer tools (Network tab → click the image request → Headers). ### 7. OG Tags and Twitter Card Tags Are in Conflict LinkedIn and Facebook use Open Graph tags. Twitter/X uses its own system called Twitter Cards.<sup>[6]</sup> Most platforms will fall back to OG tags if Twitter Card tags are absent, but when *both* sets of tags are present and they conflict — different titles, different images — some platforms get confused and render the wrong one, or switch between them unpredictably. Common conflict scenario: A developer added OG tags pointing to a landscape banner image, and later a marketing team member added Twitter Card tags pointing to a square logo. LinkedIn now shows the square logo instead of the banner. **How to fix it:** Audit both sets of tags together. For most pages, the `og:` and `twitter:` equivalents should be identical unless you have a deliberate reason to show different content on different platforms. If you want consistency, set Twitter Card tags explicitly to match your OG tags: ```html <meta name="twitter:card" content="summary_large_image" /> <meta name="twitter:title" content="Your Page Title" /> <meta name="twitter:description" content="A short description." /> <meta name="twitter:image" content="https://example.com/images/preview.jpg" /> ``` ### 8. LinkedIn's Inspector Has Its Own Quirks LinkedIn's scraper behaves differently from Facebook's and Twitter's in a few notable ways: - **It doesn't follow all redirects.** LinkedIn's scraper will sometimes stop at the first redirect and read tags from the intermediate URL, not the final page.<sup>[2]</sup> - **It respects `X-Frame-Options` and some `robots.txt` rules.** If your `robots.txt` disallows the LinkedIn crawler (`Linkedinbot`), previews will fail. - **Image CDN authentication.** If your OG image is behind any kind of authentication, token, or signed URL that expires, LinkedIn will successfully scrape it the first time but fail on subsequent attempts when the token expires. - **It's slower to clear its cache.** Even after using the Post Inspector to force a re-scrape, LinkedIn posts that were already published with the old preview may not update — this is by design. **How to fix it:** Run your URL through the [LinkedIn Post Inspector](https://www.linkedin.com/post-inspector/) before publishing, not after. Treat it as a preflight check every time you share an important link. Make sure your `robots.txt` allows `Linkedinbot`. Serve your OG images from a public, permanent URL with no authentication or expiring tokens. ## Quick-Reference Checklist Use this before sharing any important link: | Check | Pass condition | |---|---| | `og:title` present | Yes | | `og:description` present | Yes | | `og:image` present | Yes | | `og:url` present and canonical | Matches the final destination | | Image dimensions | At least 1200 × 630 px | | Image file size | Under 1 MB (ideally under 500 KB) | | Image MIME type | `image/jpeg`, `image/png`, or `image/webp` | | Redirect hops to final page | 1 or fewer | | No expired/authenticated image URLs | Yes | | LinkedIn Post Inspector cleared | Run before publishing | | Twitter Card tags consistent with OG tags | Yes | ## Why This Matters Beyond Aesthetics A broken preview isn't just a cosmetic problem. Research consistently shows that posts with rich image previews receive significantly higher engagement than text-only link posts. LinkedIn's own data indicates that posts with images receive **98% more comments** than those without.<sup>[2]</sup> On Facebook, link posts with optimized previews consistently outperform those without in both organic reach and paid ad performance. If you're running any kind of content distribution — blog posts, landing pages, product pages, press releases — fixing Open Graph tags is one of the highest-return 30-minute investments you can make. ## References **[1]** Meta Platforms, Inc. (2010, ongoing). *The Open Graph Protocol*. ogp.me. <https://ogp.me/> **[2]** LinkedIn. (2024). *Share on LinkedIn — Developer Documentation: Best Practices*. LinkedIn Developer Platform. <https://learn.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/share-on-linkedin> **[3]** Fielding, R., Nottingham, M., & Reschke, J. (2022). *RFC 9110: HTTP Semantics*, §15.4 (Redirection). Internet Engineering Task Force (IETF). <https://www.rfc-editor.org/rfc/rfc9110#section-15.4> **[4]** Meta for Developers. (2024). *Sharing Best Practices for Websites & Mobile Apps*. <https://developers.facebook.com/docs/sharing/best-practices/> **[5]** Freed, N., & Borenstein, N. (1996). *RFC 2046: MIME Part Two — Media Types*. IETF. <https://www.rfc-editor.org/rfc/rfc2046> **[6]** X Corp. (2024). *Cards — X Developer Platform*. <https://developer.x.com/en/docs/twitter-for-websites/cards/overview/abouts-cards> --- *Last updated: May 2026. See also: [Link Shortening Glossary](/glossary) — Open Graph / OG tags, Social preview, Canonical URL, Redirect chain.* Q: What is an Open Graph tag? A: Open Graph (OG) tags are hidden HTML meta tags in a page's <head> that tell social platforms — LinkedIn, Facebook, Slack, iMessage — what title, description, and image to show in the link preview card. The protocol was published by Facebook in 2010 and is now the universal standard. Q: What size should an Open Graph image be? A: 1200 × 630 pixels (a 1.91:1 aspect ratio) is the safe default for LinkedIn, Facebook, and most other platforms. Keep the file under 1 MB — ideally under 500 KB — to avoid scraper timeouts. Q: Why does LinkedIn show an old preview after I updated my OG tags? A: LinkedIn aggressively caches previews. Run your URL through the LinkedIn Post Inspector (linkedin.com/post-inspector/) to force a fresh scrape. Posts that were already published with the old preview will not update — that's by design. Q: Do redirects break Open Graph previews? A: Yes. Some scrapers (LinkedIn especially) read OG tags from the intermediate URL rather than the final destination, or stop following after one hop. Keep your redirect chain to a single hop, and make sure the final page has correct OG tags. ### Linktree Alternatives (2026): Free and Paid Picks Compared — https://uselinkpilot.com/blog/best-linktree-alternatives Published: 2026-05-16 · By LinkPilot Team Linktree alternatives compared: LinkPilot, Beacons, Linkin.bio, and Bio.fm on free links, per-link analytics, custom domains, QR codes, and branding. Linktree pioneered the "one link in bio" pattern, but in 2026 you have better, cheaper, and more flexible options. This guide compares the **best Linktree alternatives** based on what actually matters: analytics depth, custom domain support, free-tier limits, and how cleanly your page looks in the wild. We've spent time inside each platform's dashboard — these are not affiliate roundups dressed up as advice. ## How we evaluated A bio link page is a tiny piece of marketing infrastructure. The differences that matter on day 100 — not day 1 — are: - **Analytics depth.** Do you get per-link clicks, referrer data, and geography, or just a daily total? - **Custom domain.** Can you put the page on `you.com/links` instead of `linktr.ee/you`? This compounds brand value over time. - **Free-tier branding.** Does the free plan show the vendor's logo on your page, and how prominently? - **A/B and reordering.** Can you change link order, hide stale links, and test which top link converts best? - **QR codes.** Can you generate a scannable QR for offline use without jumping to a separate tool? - **Pricing transparency.** Is the upgrade path predictable or are key features (analytics, domains) locked behind a high tier? ## The shortlist ### 1. LinkPilot — best for analytics-driven creators LinkPilot bundles a bio link generator with the same analytics engine that powers our enterprise link management product. You get per-link click counts, geographic breakdown, and referrer data on the free tier — no upgrade required. - **Free tier**: unlimited links, click analytics, basic theming, optional removable branding on paid plans. - **Custom domain**: included on all paid plans (from $9/mo). - **QR codes**: built-in, downloadable as PNG or SVG. - **Best for**: creators who actually want to know which post drove the bio tap. [[tool:bio-link-generator]] ### 2. Beacons — best design and templates Beacons leans hardest into visual polish. The template library is the deepest of any free alternative, and the drag-and-drop editor is the most forgiving for non-designers. - **Free tier**: unlimited links, basic analytics, Beacons branding shown. - **Custom domain**: paid plans only. - **QR codes**: built-in. - **Best for**: creators who care more about *how it looks* than *what it measured*. ### 3. Linkin.bio (by Later) — best for scheduled-content workflows If you already use Later to schedule Instagram, Linkin.bio turns each scheduled post into a link automatically. The "shop the post" pattern they pioneered is still the cleanest UX in the category. - **Free tier**: limited to your Later plan's post quota. - **Custom domain**: paid plans only. - **Best for**: ecommerce and lifestyle creators already living in Later. ### 4. Bio.fm — best for minimalists Bio.fm strips everything down to a clean list of links. No templates, no themes, no upsells in your face. Refreshing if you want the page to fade into the background. - **Free tier**: unlimited links, minimal branding. - **Custom domain**: paid only. - **Best for**: writers, devs, and creators who want zero distraction. ### 5. Linktree — still the default, but losing ground The original. The interface is the most polished and the free tier is generous, but the analytics are thin and the upgrade prompts are relentless. You're paying with your attention even on the free plan. - **Free tier**: unlimited links, top-line clicks only, prominent Linktree branding. - **Custom domain**: only on the $9+ Pro plan. - **Best for**: creators who want the most familiar option and don't care about deep analytics. ## Side-by-side comparison | Platform | Free links | Per-link analytics (free) | Custom domain | QR codes | Free-tier branding | |---|---|---|---|---|---| | **LinkPilot** | Unlimited | Yes | Paid ($9+/mo) | Built-in | Subtle, removable on paid | | **Beacons** | Unlimited | Basic | Paid | Built-in | Visible | | **Linkin.bio** | Limited by Later plan | Yes | Paid | No | Visible | | **Bio.fm** | Unlimited | Basic | Paid | No | Minimal | | **Linktree** | Unlimited | Daily totals only | Pro ($9+/mo) | Pro only | Prominent | ## Which one should you pick? - **You want real analytics on the free tier** → LinkPilot - **You want the prettiest templates** → Beacons - **You're already scheduling on Later** → Linkin.bio - **You want zero noise** → Bio.fm - **You want the option everyone recognizes** → Linktree ## How to migrate from Linktree in 30 minutes 1. **Export your link list.** Linktree doesn't offer a one-click export, so screenshot or copy your current page. Most creators have 5–15 links. 2. **Recreate on the new platform.** Add links in the same order. Set thumbnails or icons if the platform supports them. 3. **Update your social bios.** Swap the URL in every bio (Instagram, TikTok, X, YouTube, LinkedIn). This is the only step that actually moves traffic. 4. **Set a redirect from the old URL for 2–4 weeks.** Linktree doesn't support this natively — instead, leave your Linktree page up with a single link to the new page for a transition period. 5. **Generate a QR code** for your new bio URL and use it on print, video end-screens, and packaging. [[tool:qr-code-generator]] ## The bottom line For most creators in 2026, the right Linktree alternative is whichever one ships **the analytics you'll actually look at**. Beautiful templates fade. Knowing which post drove the bio tap compounds. If you want to try LinkPilot's bio link page — with click analytics on the free tier and no migration friction — start with the [bio link generator](/tools/bio-link-generator). No signup required to preview the page. Q: Is there a truly free Linktree alternative? A: Yes. LinkPilot, Beacons, and Linkin.bio all ship a free tier with unlimited links. The trade-offs are usually around custom domains, click analytics depth, and removable branding — covered in the comparison table below. Q: Can I move my Linktree page to another service? A: Yes — there's no lock-in on the URL itself. Recreate your links on the new service, update your social bios to point at the new page, and optionally set a redirect from your old Linktree URL for a few weeks. Q: Do bio link pages hurt SEO? A: Not for the destination links — most bio link platforms use 302 redirects, which pass intent without consolidating ranking signals. They're also a useful funnel for measuring which social platform actually drives clicks. Q: What should I look for when picking a Linktree alternative? A: In order of importance for most creators: (1) custom domain support, (2) per-link click analytics, (3) ability to A/B test link order, (4) clean branding on the free tier, (5) easy QR code generation for offline use. ### The Modern Guide to Link Tracking in 2026 — https://uselinkpilot.com/blog/modern-link-tracking Published: 2026-05-01 · By LinkPilot Team Link tracking has evolved beyond click counts. Here's how modern teams measure source, intent, and conversion in a privacy-first world. Link tracking used to mean two numbers: clicks and the day they happened. In 2026, the bar is higher. Marketing teams need to know **who clicked, from where, on what device, with what intent** — without violating user privacy. This guide walks through the tracking layers that matter today and how to implement them without becoming a surveillance company. ## Why click counts are no longer enough A raw click count tells you almost nothing. Two links with 1,000 clicks each can have wildly different value: - One drives 50 signups; the other drives 0. - One is 90% bot traffic; the other is 100% human. - One concentrates in a single high-intent country; the other is scattered. Modern link tracking layers in **device class, geo, referrer, bot classification, and conversion attribution** so you can make actual decisions. ## The five layers of modern link tracking ### 1. Identity (without identifiers) Hash the IP with a daily-rotated salt. You get unique-visitor counts and abuse detection without storing PII. LinkPilot rotates salts every 24 hours, so yesterday's fingerprints can never be re-derived. ### 2. Source Capture the `Referer` header and parse the UTM parameters server-side. If both are missing, classify the click as `direct` rather than guessing. [[tool:utm-builder]] ### 3. Device + bot classification Parse the User-Agent into `mobile | desktop | tablet` and run it through a known-bot list. Bot clicks should be logged but excluded from default analytics views — keep them one toggle away. ### 4. Geo Use the edge location of the redirect (Cloudflare or your CDN headers). Country + region is plenty; storing city-level geo is rarely worth the privacy cost. ### 5. Conversion Track the downstream event the click was supposed to drive. A signup, a purchase, a download. This is where attribution lives — and where most teams stop too early. ## Common mistakes - **Trusting client-side trackers as the source of truth.** They miss 20-40% of clicks because of ad blockers and third-party cookie restrictions. - **Logging raw IPs.** Even short-lived storage is a regulatory liability. - **Counting bot clicks in headline metrics.** Crawlers will inflate every newly-published link by 2-5x in the first 24 hours. - **Treating UTMs as case-insensitive.** `Email` and `email` are different campaigns in most analytics tools. Lock to lowercase. ## What good looks like A modern link tracking stack should answer four questions in under five clicks: 1. Where is the traffic coming from? 2. Is it real? 3. Is it converting? 4. Has anything changed in the last 24 hours? LinkPilot is built around exactly that loop — server-side tracking, privacy- first hashing, and AI-powered anomaly detection that flags spikes and drops before you have to go looking for them. Q: Is link tracking GDPR-compliant? A: Yes — when implemented correctly. LinkPilot hashes IPs with a daily-rotated salt and never stores raw identifiers, which keeps tracking compliant under GDPR and CCPA. Q: Do I need cookies to track links? A: No. Server-side click tracking on a redirect endpoint captures source, device, and geo without setting any cookies on the destination. Q: What's the difference between a tracked link and a UTM link? A: A tracked link logs every click server-side. A UTM link adds source/medium/campaign parameters to the URL itself so destination analytics tools (e.g. GA4) can attribute traffic. Use both together. ### UTM Parameters: The Complete 2026 Playbook — https://uselinkpilot.com/blog/utm-parameters-complete-playbook Published: 2026-04-25 · By LinkPilot Team Everything you need to standardize, govern, and actually use UTM parameters across your team — with templates for every channel. UTMs are the closest thing marketing has to a universal language — and most teams still get them wrong. The fix is not memorizing parameter names; it's governance. ## The five parameters, decoded | Parameter | Purpose | Example | | -------------- | -------------------------------- | ---------------------- | | `utm_source` | Where the traffic comes from | `linkedin` | | `utm_medium` | The channel type | `social`, `email`, `cpc` | | `utm_campaign` | The named initiative | `q2-launch` | | `utm_term` | Paid keyword (paid search only) | `link+shortener` | | `utm_content` | Variant / placement / creative | `hero-cta`, `v2` | If you only enforce one rule, enforce **lowercase, no spaces, hyphens only**. Half of all "weird analytics anomalies" are just a stray capital letter. ## A UTM governance system that actually sticks 1. **Pick a builder, not a spreadsheet.** Spreadsheets drift. A builder with validation enforces the conventions automatically. 2. **Standardize medium values.** `social`, `email`, `cpc`, `display`, `referral`, `affiliate`, `partner`. That's the list. 3. **Use a campaign naming convention.** `<quarter>-<theme>-<channel>` works well: `q2-launch-paid`. 4. **Audit weekly.** Pull your `utm_source` distinct list. Anything weird? Fix it now before it pollutes the next quarter. [[tool:utm-builder]] ## Templates by channel ### Email ``` utm_source=newsletter utm_medium=email utm_campaign=q2-launch utm_content=primary-cta ``` ### LinkedIn organic ``` utm_source=linkedin utm_medium=social utm_campaign=q2-launch utm_content=hero-image ``` ### Google Ads ``` utm_source=google utm_medium=cpc utm_campaign=q2-launch utm_term={keyword} utm_content={adgroupid}-{creative} ``` ### Podcast read ``` utm_source=podcast-marketing-against-the-grain utm_medium=referral utm_campaign=q2-launch utm_content=midroll ``` ## What to *never* do - Don't put UTMs on your homepage's internal navigation. You'll overwrite organic source attribution. - Don't use UTMs on indexable inbound links — search engines will index the parameterized URL as a duplicate. - Don't track campaign IDs only — humans need to read the value six months from now. ## Where shortened links fit in UTMs are ugly. Wrap them in a branded short link so the social copy stays clean and the parameters survive every paste, scrape, and forward. That combination — a clean short link in front, a governed UTM on the back — is the foundation of every modern attribution stack. Q: What are the five standard UTM parameters? A: utm_source (where), utm_medium (channel type), utm_campaign (campaign name), utm_term (paid keyword), and utm_content (variant or placement). Q: Should UTMs be lowercase? A: Yes. Most analytics tools treat parameters as case-sensitive, so 'Email' and 'email' show up as separate sources. Lock everything to lowercase at the source. Q: Do UTMs hurt SEO? A: No, when used on outbound campaign links. Avoid putting UTMs on internal links or links you want indexed — they fragment your link equity. ### QR Codes That Actually Convert: Design and Placement Guide — https://uselinkpilot.com/blog/qr-codes-that-convert Published: 2026-04-18 · By LinkPilot Team Most QR codes get scanned, then abandoned. Here's the design and placement playbook that turns scans into customers. The hard part about QR codes was never the technology — it's the *moment*. Someone has half a second to decide whether scanning is worth it. Most QRs fail that test before the camera even opens. This is the playbook we use to design QR campaigns that survive contact with real people. ## The three failure modes 1. **No reason to scan.** A naked QR with no value proposition is a closed door. Always pair the code with a one-line promise: *"Scan to claim", "Scan for the menu", "Scan for the playlist".* 2. **Bad placement.** Below knee level, behind glare, on a moving surface. QRs need stillness, light, and roughly arm's-length distance. 3. **Broken landing page.** The destination loads slowly, isn't mobile-first, or asks for a signup before delivering the promise. Scanners bounce in under three seconds. [[tool:qr-code-generator]] ## Design rules that hold up in print - **Contrast first.** Dark code on a light background, always. Inverted QRs (light code on dark) are unreadable on most older Android cameras. - **Quiet zone of at least 4 modules.** That's the white border around the code — without it, scans drop by 30%+. - **Error correction level H** when adding a brand mark. You can occlude up to 30% of the code without breaking it. - **Test at print size.** A QR that scans on screen will not necessarily scan on a 5×5 cm matte sticker. ## Placement that converts | Surface | Minimum size | Notes | | ---------------- | ------------ | ---------------------------------- | | Business card | 2 × 2 cm | Top-right corner, standalone | | Restaurant menu | 3 × 3 cm | Top of menu, near "Order now" copy | | Storefront window| 8 × 8 cm | Eye-level, away from glare | | Conference booth | 15 × 15 cm | Pair with a one-line CTA | | Billboard | 80 × 80 cm | Test from the actual driving lane | ## Always use dynamic QRs for campaigns Static QRs encode the destination URL directly into the pixels. If the destination changes, the code is dead. Dynamic QRs encode a short link that you control. You can: - Repoint the destination after the print run ships. - Track scans, geo, and time-of-day per code. - Run A/B tests on landing pages without reprinting. - Retire campaigns cleanly without orphan QRs in the wild. ## What to measure Scans alone are vanity. The metrics that matter: 1. **Scan-through rate** — scans ÷ impressions (foot traffic, mailers, etc.) 2. **Time-on-destination** — anything under 5 s is a broken landing page 3. **Conversion** — the actual outcome (signup, order, redemption) 4. **Geo concentration** — does the campaign work where you expect? Treat QR codes as attributable channels, not novelties, and the budget will follow the results. Q: What's the smallest QR code that still scans? A: As a rule of thumb, the QR should be at least 1/10th the typical viewing distance — for a poster viewed from 2 m, that's 20 cm. Test with the cheapest phone you can find before printing. Q: Should I use a static or dynamic QR code? A: Always dynamic for marketing use. A dynamic QR resolves to a short link you can repoint without reprinting. Static QRs encode the destination directly and are permanent. Q: Does a custom-branded QR scan as reliably as a plain one? A: Yes, if you keep the error correction at level H (30%) and the brand mark inside the central safe zone. Test on three devices before mass production. ### The Creator's Smart Link Stack — https://uselinkpilot.com/blog/creator-smart-link-stack Published: 2026-04-10 · By LinkPilot Team How full-time creators turn a single bio link into a measurable, monetizable funnel — without paying for five separate tools. The economics of being a full-time creator are brutal: every audience touch point has to do real work. A bio link that just lists "my Patreon, my Substack, my latest video" leaves money on the table. The creators making a living from this treat their smart-link stack as infrastructure, not decoration. ## The stack A working creator stack has four layers: 1. **Bio page** — the always-on hub. 2. **Campaign-specific short links** — for collabs, sponsorships, episodes. 3. **CTA inventory** — pre-written, tested, ready to paste. 4. **Attribution loop** — what's actually driving sales. [[tool:bio-link-generator]] ## Layer 1: the bio page Three rules: - **One primary CTA above the fold.** The thing you most want this week. - **No more than five total links.** Past five, CTR collapses. - **Weekly rotation.** The top link should match whatever you're posting about *right now* — not what you launched in February. ## Layer 2: campaign-specific links When a brand sponsors a video, give them a unique short link. When you appear on a podcast, give the host their own. This isn't paranoia — it's the only way to know which collabs are worth doing again. A naming convention helps: ``` yourbrand.link/sp-tabletalk yourbrand.link/yt-feb-rant yourbrand.link/ig-reel-feb24 ``` ## Layer 3: CTA inventory Most creators write CTAs on the fly and they all sound the same: *"link in bio"*. Build a library of tested phrasings instead. Examples that consistently outperform "link in bio": - *"Full breakdown — link's pinned in my bio."* - *"Steal my exact template (free) — bio link."* - *"This took me 6 months to figure out. Bio."* The pattern: name the value, then name the action. AI CTA generators are useful for breaking out of your own phrasing rut — generate 20, keep two, test weekly. ## Layer 4: attribution Two questions to answer every Sunday: 1. Which platform sent the most engaged traffic this week? 2. Which CTA wording converted best? If you don't know, your stack isn't working. The fix is rarely "more content" — it's tighter measurement. ## The cost of *not* doing this Most creators run on Linktree + intuition. That's fine for hobby accounts. For a business, it means: - No idea which collaborations actually pay back. - No idea which CTA wording pulls. - No idea whether the audience growth is converting. The smart-link stack closes that loop. Once you have it, every post is an experiment with results, not a shot in the dark. Q: Do I need a link-in-bio tool if I already have a website? A: Yes — your homepage is built for desktop browsers and search engines. A bio page is built for vertical mobile scrolls and three-second decisions. They serve different jobs. Q: How many links should I have in my bio? A: Three to five. Every additional link reduces the click-through rate of the top one. Reorder weekly based on what you're actively promoting. Q: Can I A/B test bio links? A: Yes. Swap the top link's wording weekly and compare CTR. Anything below 8% means the offer or wording isn't pulling its weight. ### Beyond Last-Click: Practical Multi-Touch Attribution — https://uselinkpilot.com/blog/practical-multi-touch-attribution Published: 2026-04-02 · By LinkPilot Team Last-click attribution is lying to you. Here's a practical framework for multi-touch attribution that doesn't require a data team. Last-click attribution is the friend who shows up at the end of a long project and takes credit for everything. It's not malicious — it's just how the default analytics view works. And it consistently steers budget toward the wrong channels. You don't need a data team to fix this. You need three things: a UTM discipline, a click log you trust, and a model. ## Why last-click breaks teams Imagine a customer journey: 1. Sees a YouTube ad → forgets about it. 2. Reads a blog post that ranks for *"link tracking"* → bookmarks the site. 3. Three days later, types the brand name into Google → converts. Last-click attributes the sale to **branded search**. The YouTube ad and the blog post — the actual demand drivers — get zero credit. A few quarters of that and the budget consolidates into bottom-of-funnel channels that literally cannot grow because nothing is feeding them. ## A practical multi-touch framework You need three layers: ### 1. Capture every touch Wrap every outbound link in a tracked short link with UTMs. The shortener logs the click server-side; the UTMs let downstream tools (GA4, your CRM) attribute the session. [[tool:utm-builder]] ### 2. Stitch sessions to identities When the user converts (signup, purchase), record the cookie ID + the UTMs of every prior session against the new account. This is the single piece of glue that makes attribution work. Most CRMs and analytics tools support this; you just have to turn it on. ### 3. Pick a model and commit Three models, in order of complexity: - **First-touch.** Credit the first known channel. Best for awareness teams. - **Last-non-direct.** Like last-click but ignores direct visits. The pragmatic default for most teams. - **Position-based (40/20/40).** First and last each get 40%, middle touches share 20%. Best for blended teams. Pick one. Use it for at least a quarter. Compare the ranking of channels to your last-click ranking. The differences are the channels you've been under- or over-investing in. ## What this looks like in practice A typical spend reallocation after switching from last-click to position- based: | Channel | Last-click share | Position-based share | | -------------- | ---------------- | -------------------- | | Branded search | 38% | 22% | | Paid social | 12% | 19% | | Content/SEO | 8% | 24% | | Email | 22% | 18% | | Direct | 20% | 17% | Notice: branded search and direct shrink. Content and paid social grow. That's the demand-generation work finally showing up in the numbers. ## When to upgrade to dedicated tools You'll know it's time when: - You're spending six figures a month on paid media. - Your CRM has 5+ months of clean UTM data. - You can name three decisions that are blocked on better attribution. Before that, the upgrade has negative ROI. Discipline beats software at this stage. Q: What's wrong with last-click attribution? A: It gives 100% of the credit to the final touchpoint, which is usually a branded search or direct visit. That makes top-of-funnel channels look worthless even when they're driving the demand. Q: Do I need an attribution tool to do multi-touch? A: No. A disciplined UTM strategy plus a smart-link platform that logs every click server-side gets you 80% of the way there. Dedicated tools matter once you're spending six figures a month on paid. Q: What's a position-based attribution model? A: It assigns 40% credit to the first touch, 40% to the last touch, and splits the remaining 20% across middle touches. It's the easiest model to defend in a marketing meeting.