Which Apps Still Support Custom URL Schemes in 2026

Every “URL scheme cheat sheet” that ranks on page one is a few years old, and half of what it lists no longer opens anything. A link built against yesterday’s fb://profile/<username> pattern, copied from a post that was accurate when it was written, will not open Facebook today. The schemes that still work are a much shorter list than the ones still being copied around, and the difference matters because a broken scheme doesn’t error. It just does nothing, or falls through to a browser.

That silent-failure behavior is what makes this table worth keeping current rather than trusting to memory. A scheme entry that’s wrong doesn’t throw an error a developer would catch in testing; it just fails to resolve, and on a device where the destination app happens to be installed and the visitor happens to end up somewhere reasonable anyway, a broken rewrite can go unnoticed for months.

Confirmed working, and how each one is built

Seven rewrites are confirmed working:

Telegram. Both bot and channel links map onto tg://resolve, with the domain parameter carrying the bot or channel username and start carrying whatever payload you’re passing through. The same rewrite path handles a plain channel link and a bot link with a payload, differing only in whether start is present.

Instagram. instagram://user?username=<username> is a straight username-for-username swap, no numeric id required. It’s the one profile deep link on this table that skips the identifier problem covered further down.

Facebook. The fb://profile/<n> swap looks just as direct, but only works if you already have the numeric id. A username alone doesn’t get you there, and the reason why is below.

Spotify and Twitch. Both use their custom scheme purely as a resolver for the content id already present in the https URL, with no lookup step and no format conversion, just a different envelope around the same identifier. The failure mode for both is syntax, not permissions. Get the colon or the v prefix wrong and the link is malformed, not merely unsupported.

Worked side by side, the Twitch pair shows why the syntax detail matters more than it looks like it should. A stream link, https://twitch.tv/<channel>, rewrites to twitch://stream/<channel>, a straight swap. A VOD link, https://twitch.tv/<channel>/v/<id>, rewrites to twitch://video/v<id>, where the id itself gains a v it didn’t have in the source URL. Copy the stream pattern for a VOD link and drop that prefix, and the resulting scheme references an id that doesn’t exist rather than one that’s merely malformed at the syntax level.

TikTok’s real scheme has a decoy sitting right next to it

TikTok’s iOS scheme is snssdk1233, named as such in TikTok’s own SDK documentation. The trap is snssdk1128. That’s Douyin, a different app from a different store, and the two identifiers are close enough in a copied list that swapping them is an easy, silent mistake. A link built against the wrong one won’t open TikTok. If the visitor happens to have Douyin installed, it opens the wrong app entirely.

Confirmed absent, in the vendor’s own words

The following don’t have a usable scheme, and each has a vendor-stated reason rather than an unexplained gap:

Two identifier problems, not one bug

Facebook and Instagram fail for the same underlying reason, from opposite directions.

fb://profile/ needs a numeric id, not a username, and the Graph API refuses username lookups outright, returning error #803. If all you have is a username, there’s no supported path to the numeric id the scheme requires.

Instagram has the mirror-image problem. A post or reel URL carries a shortcode, but the scheme needs an internal numeric media id, and the shortcode doesn’t convert to one through any documented route. Two different platforms, two different directions, the same shape of failure: the identifier the public URL gives you isn’t the identifier the scheme wants.

The practical consequence is the same for both: the numeric id has to be captured and stored at whatever point it’s actually available, rather than derived on demand from the username or shortcode you’re routing against. A rewrite rule that assumes it can convert one to the other at click time is building on a lookup path that doesn’t exist.

Why the list is short, and staying short

It’s worth naming the pattern directly. The narrow iOS coverage above is mostly the vendors’ own deliberate choice, not a gap in anyone’s implementation. LINE pulled line:// on purpose, citing takeover risk. YouTube’s docs point to Universal Links as the replacement, not a missing feature. Pinterest says outright it won’t publish scheme templates for third parties. Reading a shrinking scheme list as a series of implementation failures misreads what’s actually happening. This is a coordinated move toward Universal Links, and for the vendors on the absent side of this table, it’s mostly finished.

That framing matters for how you plan around this list. A scheme that’s absent today because a vendor deliberately retired it is not a candidate for rediscovery next quarter the way an undocumented gap might be. Build routing logic that treats the absent table as a settled state per vendor, not a todo list to keep probing.

When there’s no scheme, the fallback isn’t neutral either

For apps with no usable scheme, the practical fallback is a store link:

iOS: https://apps.apple.com/app/id<numeric id>

That numeric id can’t be guessed, and for a few apps it doesn’t point anywhere useful at all. Microsoft retired consumer Skype in May 2025, so there is no listing left to link to. An app can also stay perfectly installable on Android while its iOS listing is gone, which leaves the entry valid on one platform and the store fallback dead weight on the other. Shopee has no single global store page, so a store fallback would route ten of its eleven markets to the wrong country’s listing. Skipping the fallback and sending everyone to the web page is the more correct behavior there, not a compromise.

A scheme table is only half the routing problem. The other half is knowing when a store fallback genuinely helps and when it just adds a dead link with more confidence than it deserves. DarkCore’s redirect layer treats scheme and store fallback rows as data, not hardcoded assumptions, precisely because this table doesn’t hold still.

Keep this list current, not memorized

Every row above is a rewrite the vendor’s own systems accept today, in 2026, not a pattern that used to work. The absent table is equally current. Each reason is the vendor’s stated position, not an assumption filled in because nobody could find documentation. Treat both halves as perishable. A vendor moving from a custom scheme to Universal Links, the way YouTube and LINE already have, doesn’t send a deprecation notice to every site that copied its old pattern.

Re-verify against the vendor’s own current documentation before a rewrite goes into a routing config that will run unattended for months, rather than against whatever cheat sheet turned up first in a search. The seven rewrites and seven absences above are the ones with a source behind them as of this writing; everything else belongs in the “unknown” bucket until it has one too.

FAQ

Is fb://profile/<username> ever going to work?

No, and not because of how the scheme is constructed. The Graph API returns error #803 on username lookups. There’s no supported way to get from a username to the numeric id the scheme requires.

Does TikTok have an equivalent scheme on Android?

Android doesn’t use this scheme mechanism at all. Deep links there resolve through intent:// package targeting, a different chain than the one this table covers.

Why isn’t WhatsApp or Messenger on this table?

This table covers apps reachable through a rewritten custom scheme on iOS. Whether a click identifier survives a jump into a messaging app is a separate question with its own conditions, and it doesn’t follow the same working or absent split as opening the app itself.