What is a Media URL?

A media URL identifies an image, video, audio file, manifest, or generated rendition at a network endpoint. Its path and query parameters may select a source asset, transformation, or delivery policy.

How Media URLs work

A media URL is the address through which a client retrieves an original file, a rendition, a segment, or a streaming manifest. The server decides what each part means: commonly the path identifies the asset and query parameters carry transformation settings or a signature. The URL does not settle the format of the response. HTTP’s Content-Type header states the media type, so the file extension in a path does not decide what a client receives. Other response headers govern caching, byte-range delivery, and cross-origin use. A streaming manifest adds one more layer, because it is a file of further URLs: in HLS, a relative URI inside a playlist is resolved against the URL of the playlist that contains it, so the manifest URL determines where a player looks for segments.

Key facts

  1. Is the query string part of the cache key? It depends on the CDN and its configuration, so check before putting transformation parameters there. HTTP defines a cache key as, at minimum, the request method and target URI. Cloudflare’s default key includes the full URL with its query string. Amazon CloudFront’s default key contains only the distribution’s domain name and the URL path, so two URLs that differ only in a parameter such as ?w= return the same cached object until a cache policy adds that parameter to the key. Adding a parameter that does not change the response has the opposite cost: CloudFront warns that it can cache duplicate objects and lower the cache hit ratio.
  2. Does a video or audio file URL need a server that supports byte ranges? For seeking on iOS, yes: Apple’s archived Safari guidance states that servers hosting media files for iOS must support byte-range requests, which iOS uses for random access during playback. MDN describes range requests more generally as useful to media players that support random access. HTTP itself makes range requests optional, and a server may ignore the Range header and answer 200 with the whole file. A CDN can add conditions of its own: CloudFront returns the entire object instead of the requested range when the origin answers with Transfer-Encoding: chunked. Send a ranged request to the public URL, not only to the origin, and expect a 206 response with a Content-Range header.
  3. What happens to segment URLs when an HLS manifest URL is signed? A signature in the manifest’s query string is not carried over to them. Relative segment URIs are resolved against the playlist URL, and standard URI reference resolution keeps the query of the relative reference, not that of the base URL, so segment requests arrive without the signature unless the playlist is rewritten per viewer or access is granted another way. Amazon CloudFront’s documentation recommends signed cookies instead of signed URLs for giving access to multiple restricted files, and names all the files of an HLS video as its example.
  4. Can the bytes behind a URL change? If they can, a cache that holds the earlier response may keep serving it for as long as it is fresh, so give the response a short freshness lifetime or require revalidation when updates must become visible promptly. Publishing each version under a new URL avoids the problem: RFC 8246 describes versioned URLs as the pattern that allows a very large freshness lifetime without guessing when a resource will be updated, and MDN recommends a long max-age for URLs that include a version number or hash.

When Media URLs matter

Return stable media URLs when clients embed assets in pages, players, or API responses. A signed URL limits access. When it carries an expiry, requests made after that time are refused, so it does not suit long-lived references, and each new signature is a new URL to any cache whose key includes the full query string.

How Transloadit helps with Media URLs

Transloadit hands out media URLs in two ways. Each result file in an Assembly Status carries a url and an ssl_url. When a result is exported with a storage Robot such as /s3/store, the Assembly Status returns the URL of the file in your bucket. That URL locates the stored object, but it does not make a private object public or grant read access, so publish it only where viewers are allowed to read the object, and otherwise publish an authorized storage or CDN URL for it. URLs on Transloadit’s temporary storage are removed automatically and are documented as not for serving end users. A Smart CDN URL has the form https://[your-workspace].tlcdn.com/[template-name]/[file-path]?[parameters]: the Template name and file path select the workflow and the original, and the query parameters reach the Template as transformation settings. It can be signed with an exp expiry and a sig signature, and the effective cache lifetime of a signed response is bounded by the remaining signature lifetime.

For Smart CDN responses, the /file/serve Robot’s documented default headers include Accept-Ranges: bytes and a Content-Type taken from the file’s detected MIME type.

Explore Transloadit’s delivery capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free