One shortcode, three URLs: why /p/, /reel/, and /tv/ all point to the same post

The test that surprises everyone

Grab any public Reel on Instagram. Copy the link — you'll get something shaped like `https://www.instagram.com/reel/DH56yy7p3lZ/`. The eleven characters between the second and third slash are what matters. Everything else is just routing.

Now swap `/reel/` for `/p/`. Paste that into a browser. The same video plays. Swap in `/tv/` instead — same video again. Instagram doesn't care which prefix you use; the shortcode is the canonical identifier, and all three URL shapes resolve to the exact same server-side record.

This isn't a bug. It's the direct consequence of Meta's July 2022 consolidation of IGTV into the unified feed-video product, layered on top of a shortcode system that was always global across content types anyway. But somehow, in April 2026, a surprising number of third-party Instagram downloader tools still special-case URL prefixes — rejecting a pasted `/tv/` URL as "invalid" when the user's actual link was an old IGTV post that absolutely still resolves.

What an Instagram shortcode actually is

The shortcode is an 11-character base64-ish encoding of a 64-bit internal media ID. Instagram has been using this format since the early days of the app — predating Reels, predating IGTV, predating Stories. Look at a post URL from 2012 and one from 2026; the shortcode structure is identical. Only the prefix around it changed.

The alphabet in use is roughly `[A-Za-z0-9_-]`, which matches URL-safe base64. Decoding is trivial: each character maps to 6 bits, 11 characters gives you 66 bits, and the top two are padding. The remaining 64 bits are the media's globally-unique identifier in Instagram's backend — the same ID the API calls `pk` or `media_id` depending on which endpoint you're hitting.

Shortcodes are unique across Instagram. There is no namespace collision between a Reel shortcode, a feed post shortcode, and an IGTV shortcode, because there is no separate namespace. They all live in the same counter, and which product surfaces a given shortcode depends entirely on what kind of media was uploaded under that ID.

Why the URL prefix exists at all

If the shortcode is sufficient, why does Instagram bother with `/p/` vs `/reel/` vs `/tv/`?

Mostly SEO and UX routing. The `/reel/` prefix gives Google a signal that the page should be indexed and snippeted differently — a vertical video preview instead of a square photo thumbnail. The `/p/` prefix is the historic catch-all, dating back to the original app when everything was a square photo. The `/tv/` prefix was IGTV's dedicated namespace for long-form vertical video, which Meta sunsetted as a standalone product in July 2022.

Server-side, the prefix does almost nothing. Meta's backend normalizes the URL, extracts the shortcode, fetches the media record, and serves whatever it finds. If you paste a `/reel/` URL pointing to a post that was originally uploaded as a feed photo, Instagram will redirect you to `/p/` and display the photo. The reverse also happens — old `/p/` URLs that point to what's now a Reel still work.

For downloader tools like ours, the only sensible design is to ignore the prefix entirely and key off the shortcode. Which is what we do — and which is also why we accept `/p/`, `/reel/`, `/tv/`, `/reels/`, and even bare-shortcode URLs interchangeably in our paste box.

What we observed on 2026-04-23

We pasted the same shortcode (DH56yy7p3lZ, a public @natgeo Reel) into our production tool three separate times, once per URL shape:

`https://www.instagram.com/reel/DH56yy7p3lZ/` → parse returned a DASH manifest with 720p + 360p video representations plus HE-AAC audio. Total round-trip: ~16 seconds. File served: 10.6 MB MP4.

`https://www.instagram.com/p/DH56yy7p3lZ/` → identical DASH manifest, identical variants, identical 10.6 MB MP4. The creator attribution in the result card rendered as "Photo by @National Geographic" — our parser pulls attribution from the shared media record, and the label in that record is generic across content types. A minor cosmetic note that we're cleaning up; the actual download behavior is correct.

`https://www.instagram.com/tv/DH56yy7p3lZ/` → same DASH manifest, same variants. Even though IGTV as a product is three years retired, the URL pattern continues to resolve — there's no deprecation redirect, no 404, nothing. The backend just serves the media record under the shortcode and lets the client handle the rendering.

Three paste attempts, one shortcode, one file, three different URL prefixes that our tool's regex accepts and our backend treats identically. Byte-for-byte the same MP4 in all three cases (we hashed the output streams — SHA-256 matched).

What competitor tools get wrong

Pick a random Instagram downloader from search results and paste a `/tv/` URL into it. A depressing number of them will flash an error: "Please paste a valid Instagram Reel/Post URL." Their regex was written before July 2022, never updated, and now rejects perfectly-legal URLs.

Some go the other direction: they accept the `/tv/` URL, but internally rewrite it to `/reels/` before hitting Instagram's API, which works for most shortcodes but breaks the handful of old long-form IGTV videos that were never moved to the unified Reels pipeline. Those still exist — anyone who uploaded a 10-minute documentary to IGTV in 2020 and hasn't touched it since has a shortcode that lives in a weird twilight state, and a tool that assumes everything is a Reel will fail on it.

The other common failure: `instagram.com/USERNAME/p/SHORTCODE/` — the username-prefixed URL shape that Instagram shows when you're logged in and browsing a profile. Copy that from your address bar, paste it into a naive downloader, the regex fails because the URL doesn't start with `/p/`. Our paste box handles this by pattern-matching the shortcode anywhere in the URL rather than requiring a specific prefix at the root.

If you're building a tool that accepts Instagram URLs, the robust approach is: strip the protocol, strip any query string, find the 11-char base64-ish token, and use that. The prefix is diagnostic, not authoritative.

Why this matters for the average user

You don't need to understand any of this to use a downloader. But you should know a couple of practical consequences.

Start with the obvious: when you're copying a link from Instagram, it doesn't matter which UI you copied it from. The share icon under a Reel gives you `/reel/`. The share icon under a feed post gives you `/p/`. An old IGTV URL saved from 2020 has `/tv/`. All three paste into our tool the same way and produce the same result for the same underlying content.

Next — if a competitor downloader refuses a pasted URL as "invalid" when the link is clearly a real Instagram post, the problem is almost certainly in their regex, not in Instagram's backend. Try pasting the URL with the prefix rewritten. `/tv/` → `/reel/` is the most common fix. Most tools that special-case prefixes will accept the `/reel/` version.

One more shape you'll hit: `instagram.com/creator/reel/DH56yy7p3lZ/` — with the username in the path — the creator's handle is cosmetic. The shortcode is still the only thing that identifies the post. Our tool accepts both shapes; some don't. If yours doesn't, strip the username out and try again.

The consolidation nobody tells you about

Meta announced the IGTV app retirement in February 2022 and the integration into the main feed in July 2022. What they didn't announce — and what's been much harder to find documentation for — is exactly how deep the unification went on the backend.

From what we've observed: the shortcode database was always unified. The product surfaces (Reels tab, feed, IGTV tab) were never backed by separate tables — they were just different query filters over the same media records. When IGTV went away, the filters collapsed; the underlying data didn't move.

Which is why old IGTV URLs still work in 2026. The post hasn't been migrated to Reels; the post was never in a separate place to migrate from. It was always in the unified media table, and now the UI just shows it with a Reels treatment regardless of how it was uploaded.

This also explains why a video uploaded as IGTV in 2021 can show up in Reels search today. Not because anyone moved it — because the 2021 upload was always the same kind of record as a 2026 Reel upload, just surfaced under different UI.

What this means for our tool coverage

We ship separate landing pages for the different content types — [Reels Downloader](https://instayolo.com/reels-downloader), [Video Downloader](https://instayolo.com/video-downloader), [IGTV Downloader](https://instayolo.com/igtv-downloader), [Photo Downloader](https://instayolo.com/photo-downloader), [Carousel Downloader](https://instayolo.com/carousel-downloader) — because users search for those specific terms. The SEO logic is that someone googling "instagram IGTV downloader" wants a page that speaks their language even if our backend treats all of them identically.

Behind every one of those landing pages, the actual pipeline is the same. Parse the shortcode out of the URL regardless of prefix, hit Instagram's internal GraphQL endpoint, pull the media record, check what kind of media it is, return the appropriate variants. An MPD for video, a JPG/WEBP list for photos, a per-slide array for carousels.

We don't route pasted URLs to different backends based on prefix. A URL that comes in as `/tv/` hits the same `/api/parse` that a `/reel/` URL hits, because the parsing logic is about the media, not about which URL shape the user happened to paste.

The edge cases — and they are edgy

A small number of shortcodes return different content depending on prefix, and those cases are worth knowing about.

Carousel posts are the main example. A 10-slide carousel has one shortcode, but the underlying record contains 10 child edges. Paste the shortcode as `/p/` and Instagram's web UI shows the carousel with all slides. Paste it as `/reel/` and Instagram 404s, because the backend sanity-checks that Reels should be single-video and the carousel has multiple children. The shortcode is valid; the prefix mismatch is what causes the 404.

Our tool side-steps this by resolving the shortcode via the GraphQL endpoint directly rather than the URL-routing layer. We get the media record, see it's a carousel, and return all 10 slides. No 404.

Stories and Highlights live in a different URL shape entirely — `/stories/USERNAME/STORY_ID/` and `/stories/highlights/HIGHLIGHT_ID/` — and don't follow the shortcode pattern. Those are covered by the [Story Downloader](https://instayolo.com/story-downloader) and [Highlight Downloader](https://instayolo.com/highlight-downloader) separately. The URL shapes are distinct enough that no amount of prefix rewriting would unify them.

The pedantic summary

An Instagram shortcode is 11 base64-ish characters that globally identify a media record in Meta's backend.

The URL prefixes `/p/`, `/reel/`, and `/tv/` are client-side routing hints, not backend selectors. A single shortcode resolves to the same media regardless of which prefix wraps it, with one narrow exception for carousel posts pasted via `/reel/`.

Meta unified the IGTV backend into the main feed in July 2022, but the shortcode namespace was already unified — the consolidation was about the UI, not the data model.

Any Instagram downloader tool that special-cases URL prefixes is leaving failure modes on the table for its users. The robust implementation extracts the shortcode from anywhere in the URL and resolves it against the unified media record.

InstaYolo's paste box accepts `/p/`, `/reel/`, `/reels/`, `/tv/`, username-prefixed shapes (`/USERNAME/p/SHORTCODE/`), and bare shortcodes. Whichever shape you happened to copy, we'll find the shortcode and return the right file.