Migrating from imgix.video to Imgix Video

Find every .imgix.video reference

Search your codebase, CMS, or templates for the .imgix.video domain string. Migrate every subdomain you find — some accounts use multiple (for example, separate subdomains for production and staging).

Swap the subdomain

Replace .imgix.video with .imgix.net in each URL. The path and every query parameter stay exactly the same:

Before: https://your-subdomain.imgix.video/path/to/video.mp4?fm=mp4
After:  https://your-subdomain.imgix.net/path/to/video.mp4?fm=mp4

All standard rendering parameters — w, h, fit, auto, q, fm=mp4, and so on — are identical on Imgix Video and require no changes.

Translate any imgix.video-specific parameters

If your video URLs use any of the following imgix.video-specific parameters, translate them to their Imgix Video equivalents:

If you don’t use any of these parameters, you can skip this step — a plain subdomain swap is all you need.

Replacing res=medium and res=low

Unlike res=high, res=medium and res=low don’t map to one fixed width. The old platform scaled each tier differently depending on a video’s aspect ratio, so a single w= value (like w=1280 for medium) won’t reproduce the same output size across your whole library, and can even upscale portrait or square videos well past what res=medium returned.

Instead, use a bounding box with fit=max and set both w and h, not just one dimension:

w=1280&h=1280&fit=max

Setting both dimensions means the box works correctly regardless of source orientation. fit=max scales the video to fit inside the box while preserving its aspect ratio and never upscaling past native resolution, so a landscape video and a portrait video both come out correctly sized instead of one of them ending up unexpectedly large.

Review a few behavior notes

A couple of things to be aware of as you test your migrated URLs:

• HLS delivery: fm=hls is fully supported on Imgix Video — no special access is required.
• Video length: videos up to 30 minutes are supported.
• Longer videos process asynchronously: videos longer than two minutes are encoded in the background. The first request to a new URL returns a 423 status while the video is prepared; subsequent requests serve the finished video from cache. This is expected, not an error — poll the URL or check again after a few minutes.

Set an explicit bitrate for predictable file sizes

By default, Imgix picks an encoding bitrate automatically based on each video’s content. This is convenient, but it means file size for a given w/h/fit box can vary a lot from video to video, since a simple, low-motion clip and a busy, high-motion clip get encoded very differently even at the same dimensions.

If you need consistent, predictable output sizes across your library, set video-bitrate explicitly instead of relying on the default:

w=1280&h=1280&fit=max&video-bitrate=2M

This gives you one dial that behaves the same way regardless of a video’s content or orientation, rather than a size that shifts per video. video-bitrate requires fm=mp4 and accepts values from 1M to 5M.

video-codec is also worth testing alongside this. Switching from the default h264 to h265 or av1 produces meaningfully smaller files at comparable quality, but only when you aren’t setting an explicit video-bitrate — once bitrate is fixed, codec choice has little effect on file size and instead trades off for quality at that same size. h265 and av1 also have narrower browser and device support than h264, so confirm your player supports them before switching.

Re-encode very large source files before uploading

Very large master files, especially raw camera-original footage in the multiple-gigabyte range with a high source bitrate, can be slow to process or fail outright. If you have masters like this in your library, re-encode and re-upload a smaller version rather than serving the original directly. Targeting a source bitrate in the 15–20 Mbps range is usually enough to preserve visual quality while keeping file size and processing time well within normal limits, versus 40+ Mbps raw camera output.

Consider video-aq=enhanced for high-volume accounts

If your account serves a large volume of video through plain fm=mp4 requests, video-aq=enhanced is worth evaluating. The default encoding mode (video-aq=auto) uses a fast heuristic with no extra delay. video-aq=enhanced runs a deeper VMAF-based analysis to find the smallest file that meets a target visual quality, typically cutting bandwidth 15–25% on standard or high-motion content and 40–60% on lower-complexity content, at the cost of extra render credits and a short async delay (roughly 15–45 seconds) on the first request before the optimized version is cached.

This is most worth testing on accounts with meaningfully high video request volume, since the bandwidth savings scale with traffic. It’s not a good fit if your workflow can’t tolerate the async delay on first request.

Test before cutover

Request each migrated URL and confirm you get a 200 response (or the expected 423 on a first request). Compare the output — dimensions, format, thumbnail frame — against the original imgix.video URL to confirm it matches.

Deploy

Once you’ve verified your migrated URLs, roll the subdomain swap out to production. .imgix.video URLs will stop resolving after the sunset date, so confirm no cached or stale references remain anywhere in your stack.