Instagram is quietly rolling VP9 across Reels — we watched it happen to one clip
We pulled a parse of the @natgeo Reel DH56yy7p3lZ at roughly noon UTC on 2026-04-23. The vencode_tag field of the signed CDN URL read ig-xpvds.clips.c2-C3.dash_baseline_1_v1 — Meta's baseline H.264 encoding profile. We pulled it again eight hours later during a bulk-mode test. Same Reel, same shortcode. The vencode_tag now read ig-xpvds.clips.c2-C3.dash_vp9-basic-gen2_1080p. Meta had re-encoded the asset into VP9 between our two tests. This is the first VP9-in-production observation we've caught live, and it has implications.
The observation
April 23, 2026, roughly 11:30 UTC. We were running ffprobe tests against a downloaded @natgeo Reel (shortcode DH56yy7p3lZ, 60-second clip) for our MP4-metadata-stripping post. The parse response returned segments with a specific encoding profile baked into the URL's base64-encoded `efg` parameter: `vencode_tag: "ig-xpvds.clips.c2-C3.dash_baseline_1_v1"`. That translates to: Instagram's video-delivery service, clips namespace, cluster C2-C3, DASH baseline v1 profile — which is H.264 baseline, the workhorse we've been documenting across eight technical posts.
Roughly 8 hours later, around 19:30 UTC the same day, we were stress-testing our freshly-shipped bulk-downloader feature. The test input included the same shortcode (we wanted a known-good URL to validate the bulk mode's concurrency scheduler). The parse response came back with a different `vencode_tag`: `"ig-xpvds.clips.c2-C3.dash_vp9-basic-gen2_1080p"`. And at the other three resolution tiers: `dash_vp9-basic-gen2_720p`, `dash_vp9-basic-gen2_540p`, `dash_vp9-basic-gen2_360p`.
Meta had re-encoded the asset with VP9 variants somewhere in that 8-hour window. Same shortcode, same post, same creator — different codec on the delivery side.
What VP9 is, briefly
VP9 is Google's royalty-free video codec, open-sourced in 2013 as the successor to VP8. YouTube has been VP9's flagship consumer delivery path for over a decade. Compared to H.264 at equivalent quality, VP9 typically produces files 20-30% smaller, which translates to real bandwidth savings at streaming scale.
The tradeoff is decode complexity. VP9 decoding is more CPU-intensive than H.264, which matters on older mobile devices without hardware VP9 support. iPhones got hardware VP9 support in the A12 chip (2018); older iPhones decode VP9 in software with noticeable battery drain. Android hardware VP9 is widespread since roughly 2016.
For a platform Meta's size, the codec choice is a trillion-row A/B test between bandwidth savings (favoring VP9) and decoder compatibility (favoring H.264 for device ubiquity). YouTube made the bet toward VP9 early; Meta has hedged with H.264 for longer.
The historical context — experiments Meta has already run and rolled back
Instagram experimented with HEVC (H.265) for some creator-pro uploads in 2023. HEVC has better compression than H.264 but the tooling is patent-encumbered and decoder support in browsers has historical gaps (Safari: yes, Chrome: yes since 2022, Firefox: still limited). Meta rolled back most of the HEVC pilot by late 2024 without public commentary.
Instagram tried AV1 for some web-surfaced Reels in early 2024. AV1 is the royalty-free successor to VP9, with another 20-30% compression win over VP9 at equivalent quality. Browser support for AV1 decode is solid (Chrome, Firefox, Safari all decode it since 2023), but mobile hardware decode is still inconsistent — iPhones got hardware AV1 in A17 Pro (2023), Android flagships in 2022 chips. Meta rolled the AV1 experiment back by mid-2024.
VP9 sitting in-between those two — better compression than H.264, widely supported in hardware since 2018-ish, royalty-free like AV1 but with more decoder maturity — makes it a sensible middle-ground bet. And the encoding profile we observed (`vp9-basic-gen2`) implies this is Meta's second-generation VP9 pipeline, not a first attempt.
How we know it was a re-encode, not a different asset
The `efg` parameter's base64-decoded JSON includes two fields that pin this down. `xpv_asset_id: 1170775294179927` — Instagram's internal 64-bit asset identifier — was identical across both parse calls. Same asset record. `asset_age_days: 386` was also identical, meaning the asset was 386 days old on both parses — no re-creation, just a re-packaging.
The `oh=` signature and `oe=` expiry were different, which is expected — each parse call generates a fresh signed URL with ~108-hour TTL (see our CDN URL signature anatomy post for the full breakdown). Those fields rotate per signing session even when the underlying asset hasn't changed.
The `vencode_tag` is the tell. It identifies the encoding profile used to produce the DASH variants. That string changing between two parses against the same `xpv_asset_id` means Meta's backend re-encoded the same source into a new profile and the URL generator is now pointing at the new variants.
Why Meta might be doing this now
Three likely drivers. The first is straightforward economics. 20-30% smaller files at the same perceived quality means 20-30% lower CDN egress costs. At Meta's scale — a billion Reels played daily — that's real money even factoring in the re-encoding compute.
The second is competitive pressure. TikTok's CDN has been using VP9 and AV1 for years. Instagram's continued reliance on H.264 means they ship bigger files than their nearest competitor for the same quality, which matters for users on metered connections. Cutting that gap is strategic.
The third is infrastructure maturity. Meta's edge fleet has been adding VP9 hardware decode support alongside H.264 for years. The compatibility risk that held them back from rolling VP9 to general Instagram traffic is smaller today than it was in 2020. Their browser-side clients (the Instagram web player, the mobile apps) all support VP9 decode either in hardware or in software.
What this means for downloaders
Tools that pull video via yt-dlp's Instagram extractor (including ours) should just work. yt-dlp handles VP9 natively and has for years — it was built for YouTube, where VP9 has been the primary codec since forever. The DASH manifest parsing doesn't care what codec the variants are; it reads the `codecs` attribute from each representation and hands the URLs back to whoever asked.
Tools that hard-coded H.264-specific assumptions in their pipeline (or in their UI copy) will need updates. If a downloader advertises "H.264 output always" as a feature, that claim becomes false for any Reel Meta has flipped to VP9.
Our own pipeline is agnostic — ffmpeg's `-c copy` remux copies whatever codec the source has, so a VP9 DASH stream comes out as a VP9 MP4. Container-wise that's perfectly legal (MP4 supports VP9 since the ISO/IEC 14496-15:2017 amendment); playback-wise, most modern video players handle it.
Playback implications for end users
A VP9 MP4 plays in: Chrome, Firefox, Edge, Safari (since macOS Sonoma / iOS 17), VLC, MPV, any modern smart TV, Windows Media Player (with codec pack), Plex, Jellyfin. That's the overwhelming majority of playback contexts.
Where it doesn't play natively: Apple QuickTime Player on older macOS (pre-Sonoma), old smart TVs, some car infotainment systems, legacy mobile apps that hardcoded H.264 AVC1 parsing. For those edge cases, VLC is the universal escape valve — it decodes VP9 in software on every platform.
For the InstaYolo user who downloads a Reel to watch offline on their iPhone, the transition is invisible. VP9 hardware decode on iPhone has been standard since 2018, the Photos app handles it, iMovie handles it, standard share-sheet flows all handle it. We're not aware of any iOS user-facing regression.
File-size deltas we'd expect
We didn't yet capture a before-and-after size comparison for the same Reel at the same resolution tier because our first parse fetched an H.264 file and the second parse fetched VP9 — different files, not strictly the same source bytes. The bitrate field in the efg suggests the 1080p VP9 variant is running at ~1.49 Mbps (`bitrate: 1492859`) for a 60-second clip, versus the ~1.36 Mbps we previously observed for the same clip at 720p H.264 (`bitrate: 1356360`).
A 1080p VP9 at 1.49 Mbps versus a 720p H.264 at 1.36 Mbps isn't the apples-to-apples comparison that proves VP9's compression advantage. For that we'd need same-resolution same-source comparisons, and we'll capture those as more Reels flip over in the coming weeks.
The anecdotal pattern holds though — VP9 at 1080p running on roughly the same bandwidth budget as H.264 at 720p is consistent with VP9's compression profile. Meta saves the bandwidth and users get an apparent quality bump.
What to watch for next
Which Reels get flipped and which stay on H.264. Our hypothesis is that Meta is rolling VP9 selectively based on asset age, popularity, or creator tier. The @natgeo Reel we observed is a popular public clip from a verified account — exactly the kind of asset that benefits most from bandwidth savings because it's played often.
Whether the flip is one-way or reversible. We'll check back on the same asset over the coming weeks to see if it stays on VP9 or rotates back to H.264 variants. Either behavior would be informative.
Whether Meta ships the VP9 variants alongside H.264 (dual-delivery) or as a full replacement. The DASH manifest can technically carry both codecs as alternate representations and let the client pick; that would maximize compatibility but cost Meta double the storage.
Whether AV1 shows up in the `vencode_tag` field. If we see `dash_av1-*` tags appear alongside `dash_vp9-*`, that'd be Meta dual-rolling the next codec generation too. Worth tracking because AV1 plus hardware decode becomes the long-term winner on bandwidth if/when devices catch up.
How you can check this yourself
Paste any Instagram Reel URL into a parse tool that exposes the raw CDN URLs — ours does via `/api/parse` (POST with `{"url": "..."}` in the body). Extract the `efg` query parameter from the returned video URL. Base64-decode it. Look for the `vencode_tag` field.
`dash_baseline_1_v1` means H.264 baseline — the old default. `dash_vp9-basic-gen2_<resolution>` means VP9 — the new rollout. If you see `dash_hevc-*` that'd be HEVC (the rolled-back 2023 experiment; don't expect it). If you see `dash_av1-*`, you've found an AV1 variant — tell us at /contact, we'd love to track which creators got selected.
Our full breakdown of every query parameter in the signed CDN URL lives at https://instayolo.com/blog/instagram-cdn-url-signature-anatomy.
The honest summary
One data point isn't a trend. What we've caught is one public Reel from one popular creator flipping from H.264 to VP9 between two tests in one day. Meta's codec pipeline has been evolving for years; this is a visible tick of that evolution, not a surprise launch.
For downloader users: nothing breaks. Our tool and most others handle VP9 transparently. The output file is a VP9 MP4 instead of an H.264 MP4 — same-container, different stream inside. Playback is invisible unless you're on a device that pre-dates 2018.
For anyone building an Instagram-adjacent tool: if your pipeline hardcodes H.264 assumptions, start updating. The VP9 variants are on the CDN today for at least some assets; over time they'll reach more.
Other pieces of the puzzle we've documented: [inside Instagram's DASH manifest](https://instayolo.com/blog/instagram-dash-streaming-explained), [MP4 metadata stripping on upload](https://instayolo.com/blog/instagram-mp4-metadata-stripping), [CDN URL signature anatomy](https://instayolo.com/blog/instagram-cdn-url-signature-anatomy), [HDR metadata stripping](https://instayolo.com/blog/instagram-strips-hdr-metadata), [4K Reel upscale myth](https://instayolo.com/blog/the-4k-instagram-reel-myth), [shortcode namespace unification](https://instayolo.com/blog/instagram-shortcode-namespace-explained), [residential proxy deployment](https://instayolo.com/blog/how-residential-proxies-bypass-instagram-cdn), [CORP block fix](https://instayolo.com/blog/instagram-cdn-cors-block-thumbnail-fix).
FAQ
- Can my device play VP9 Instagram Reels?
- Almost certainly yes. VP9 hardware decode is standard on iPhones since A12 (2018), Android since ~2016 flagships, all current desktop browsers, most smart TVs. VLC decodes VP9 in software on any platform. The only real edge cases are pre-2018 iPhones, very old smart TVs, and some car head-units — for those, VLC is the universal fallback.
- Does this affect the quality of my Instagram downloads?
- Quality stays at Instagram's CDN ceiling (1080p, capped on Meta's side). The codec change is about how efficiently that quality is encoded, not how much quality there is. VP9 at a given resolution typically looks at least as good as H.264 at the same bitrate, often slightly better thanks to better intra-frame prediction. Our ffmpeg -c copy remux preserves whatever's on the CDN — no quality loss on our side.
- Will my existing downloads still play?
- Yes — files you already downloaded as H.264 before this transition are unchanged. They're sitting on your disk as H.264 MP4s and will play on anything that plays H.264 (which is still everything that plays video). Only new downloads of Reels Meta has re-encoded will come down as VP9.
- How do I tell if my downloaded Reel is H.264 or VP9?
- Run ffprobe on the file. Look at the codec_name field in the video stream. h264 means H.264. vp9 means VP9. If you didn't install ffmpeg, the macOS / Windows file info dialog usually reports the codec under Properties → Details (Windows) or Get Info → More Info (macOS).
- Will InstaYolo support AV1 if Meta rolls it out next?
- Yes — our pipeline is codec-agnostic. ffmpeg handles AV1. Whatever Meta's CDN serves, we remux into an MP4 without re-encoding. The only thing that'd change is output file size (AV1 would give us another 20-30% compression win over VP9). Compatibility-wise, AV1 is harder than VP9 for older devices, but modern playback is solid.