DEV Community: Edmond Rätzel

Stop Proxying Large Media Uploads Through Your App Server

Edmond Rätzel — Mon, 28 Sep 2026 06:37:04 +0000

Uploading a 4 GB video through your application server is an easy architecture to build.

It is also an easy architecture to regret.

The browser sends the file to your backend. Your backend receives the bytes and forwards them to object storage. That works fine for profile pictures and small documents. Once users start uploading RAW photos, long videos, or entire media collections, the application server becomes an unnecessary bottleneck.

A better pattern is to let the browser upload directly to object storage while keeping authentication and authorization inside your backend.

For large media files, multipart uploads make that pattern much more resilient.

The problem with proxying uploads

A traditional upload flow often looks like this:

Browser
   |
   v
Application server
   |
   v
Object storage

Your server now has to deal with:

long-lived HTTP connections
gigabytes of network traffic
upload timeouts
memory or temporary disk usage
retries after interrupted connections
horizontal scaling during upload spikes

The application server is performing expensive work without adding much value to the actual byte transfer.

Instead, move the data path away from your backend:

Browser ----------------> Object storage
   |
   |
   +----> Application server
           authentication
           authorization
           upload metadata
           signed upload URLs

The backend stays in control without becoming the pipe through which every file must pass.

Why multipart uploads matter

Uploading a large file as one request is fragile.

Imagine a user uploads a 3 GB video and their connection fails at 96%.

With a single PUT request, they may need to restart the entire upload.

Multipart uploading divides the file into smaller pieces:

video.mp4

part 1   10 MB
part 2   10 MB
part 3   10 MB
...
part 300

Each part is uploaded independently.

If part 187 fails, only part 187 needs to be retried.

That gives you:

resumability
parallel uploads
better progress tracking
smaller retry costs
more tolerance for unstable mobile connections

Step 1: Initialize the upload on the server

The browser should never receive permanent cloud credentials.

Instead, it asks your backend to create an upload session.

POST /api/uploads
Content-Type: application/json

{
  "filename": "wedding-film.mp4",
  "contentType": "video/mp4",
  "size": 2873948291
}

Your backend verifies the user and decides whether the upload is allowed.

app.post("/api/uploads", async (req, res) => {
  const user = requireUser(req);

  const { filename, contentType, size } = req.body;

  if (size > MAX_UPLOAD_SIZE) {
    return res.status(413).json({
      error: "File too large"
    });
  }

  if (!ALLOWED_TYPES.includes(contentType)) {
    return res.status(400).json({
      error: "Unsupported file type"
    });
  }

  const objectKey =
    `${user.id}/${crypto.randomUUID()}/${filename}`;

  const upload = await storage.createMultipartUpload({
    key: objectKey,
    contentType
  });

  res.json({
    uploadId: upload.id,
    objectKey
  });
});

Notice that the browser does not decide the final storage path.

That matters.

Never trust a client-provided object key such as:

/users/admin/private/file.jpg

Generate storage keys on the server.

Step 2: Split the file in the browser

A File object can be sliced without loading the entire file into JavaScript memory.

function splitFile(file, partSize) {
  const parts = [];

  for (let start = 0; start < file.size; start += partSize) {
    parts.push(
      file.slice(
        start,
        Math.min(start + partSize, file.size)
      )
    );
  }

  return parts;
}

For example:

const PART_SIZE = 10 * 1024 * 1024;

const parts = splitFile(file, PART_SIZE);

Choosing the right part size is a tradeoff.

Very small parts mean many HTTP requests.

Very large parts reduce the benefit of retrying individual chunks.

For large photo and video uploads, chunks in the range of several megabytes to a few dozen megabytes are often a reasonable starting point.

Step 3: Request signed URLs

Before uploading each part, the browser asks your backend for a short-lived signed URL.

POST /api/uploads/:uploadId/parts
Content-Type: application/json

{
  "partNumber": 7
}

The server verifies that:

the upload belongs to the current user
the upload is still active
the requested part number is valid

Then it generates a signed URL.

const url = await storage.signUploadPart({
  key: upload.objectKey,
  uploadId,
  partNumber,
  expiresIn: 900
});

The browser can now upload that specific part directly.

const response = await fetch(signedUrl, {
  method: "PUT",
  body: part
});

if (!response.ok) {
  throw new Error("Part upload failed");
}

const etag = response.headers.get("ETag");

Keep the returned identifier for every successful part. The storage provider typically needs those values when the multipart upload is finalized.

Add concurrency, but not too much

Uploading parts sequentially wastes bandwidth.

Uploading 200 parts simultaneously can overwhelm the browser, network, or storage API.

Use bounded concurrency.

const CONCURRENCY = 4;

A small worker pool can process parts:

async function worker(queue) {
  while (queue.length) {
    const part = queue.shift();
    await uploadPart(part);
  }
}

await Promise.all(
  Array.from(
    { length: CONCURRENCY },
    () => worker(queue)
  )
);

Four to eight concurrent transfers is usually much friendlier than firing every request at once.

Measure this on real devices. Desktop fiber connections and mobile networks behave very differently.

Retry individual chunks

Retries are where multipart uploads become especially useful.

async function retry(fn, attempts = 3) {
  let lastError;

  for (let i = 0; i < attempts; i++) {
    try {
      return await fn();
    } catch (error) {
      lastError = error;

      await new Promise(resolve =>
        setTimeout(resolve, 500 * 2 ** i)
      );
    }
  }

  throw lastError;
}

Now a failed chunk can be retried without restarting a multi-gigabyte transfer.

Be careful not to retry every error.

A 403 caused by an expired signed URL may require requesting a new URL.

A 400 caused by invalid metadata probably should not be retried at all.

Track progress from bytes, not part counts

If all chunks are equal in size, counting completed parts looks acceptable.

The last chunk usually is not equal.

Track uploaded bytes instead.

const progress =
  uploadedBytes / file.size * 100;

For detailed live progress, XMLHttpRequest still has one practical advantage over fetch: upload progress events are widely supported.

xhr.upload.onprogress = event => {
  if (event.lengthComputable) {
    updatePartProgress(
      partNumber,
      event.loaded
    );
  }
};

Aggregate progress across all active parts to display one total percentage.

Step 4: Complete the upload

Once every part succeeds, send the list of uploaded parts back to your backend.

{
  "parts": [
    {
      "partNumber": 1,
      "etag": "..."
    },
    {
      "partNumber": 2,
      "etag": "..."
    }
  ]
}

The server completes the multipart upload.

await storage.completeMultipartUpload({
  uploadId,
  key: upload.objectKey,
  parts: req.body.parts
});

Only after completion should your application mark the media object as ready.

That distinction prevents partially uploaded files from appearing in user-facing galleries.

Do not forget abandoned uploads

Users close tabs.

Laptops sleep.

Browsers crash.

Some multipart uploads will never finish.

If you ignore them, unfinished chunks may remain in object storage and generate unnecessary storage costs.

Store upload sessions in your database with states such as:

initialized
uploading
completed
aborted
expired

Then periodically clean up stale sessions.

A lifecycle rule at the storage layer can provide another safety net.

Security still belongs on the server

Direct-to-storage does not mean bypassing your backend's security model.

Your server should still control:

who may upload
maximum file sizes
accepted content types
storage keys
tenant ownership
signed URL expiration
multipart completion
database records

Also remember that browser-provided MIME types are not proof of file contents.

If uploaded media is later processed or distributed, validate it server-side before treating it as trusted.

The architecture scales better because the backend does less

The important insight is not multipart uploading itself.

It is separation of responsibilities.

Your application server handles decisions.

Object storage handles bytes.

The browser handles upload concurrency and retries.

That architecture removes a large amount of bandwidth and connection pressure from the application tier while making large uploads more resilient for users.

For media-heavy SaaS applications, that is a much healthier place to start than trying to make a traditional request-response upload endpoint survive increasingly large files.

Your Image Preview Is a Memory Leak: Managing Blob URLs in Long-Lived Web Apps

Edmond Rätzel — Mon, 21 Sep 2026 06:14:04 +0000

A user selects 40 photos, removes half of them, adds another batch, and leaves the upload page open. The thumbnails disappear when expected. The tab’s memory usage keeps climbing.

The upload endpoint may never receive a request. This problem can happen entirely inside the browser.

Local previews often start with one line:

preview.src = URL.createObjectURL(file);

That line creates a resource with a lifetime. Removing the preview element does not automatically end that lifetime.

For a long-lived application, image previews need explicit ownership and cleanup.

A blob URL is a resource handle

URL.createObjectURL() creates a URL that refers to a Blob, including a File selected through an input.

It does not upload the file or produce a permanent address. It gives browser APIs a way to consume the underlying data.

Every call creates a new URL, even for the same file:

const first = URL.createObjectURL(file);
const second = URL.createObjectURL(file);

console.log(first === second); // false

Both URLs need their own cleanup.

The browser normally releases object URLs when the document unloads. That is insufficient for a page that remains open while users process hundreds of files.

The useful rule is simple: the component that creates an object URL owns its revocation.

Make the preview own its resources

Here is a single-image preview controller. It handles replacement, failed decoding, removal, and disposal.

The HTML needs a file input, a preview container, and a status element:

<input id="file" type="file" accept="image/*">
<div id="preview"></div>
<p id="status" role="status"></p>

The controller keeps one active record:

function createPreviewController(container, status) {
  let current = null;
  let disposed = false;

  function releaseCurrent() {
    const previous = current;
    current = null;

    container.replaceChildren();

    if (previous) {
      previous.image.removeAttribute("src");
      URL.revokeObjectURL(previous.url);
    }
  }

  async function show(file) {
    if (disposed) return;

    releaseCurrent();
    status.textContent = "";

    if (!file) return;

    const record = {
      url: URL.createObjectURL(file),
      image: new Image(),
    };

    current = record;

    record.image.alt = "Preview of the selected image";
    record.image.style.maxWidth = "100%";
    record.image.style.height = "auto";
    record.image.src = record.url;

    status.textContent = "Preparing preview…";

    try {
      await record.image.decode();

      // Selection may have changed while decoding.
      if (disposed || current !== record) return;

      container.replaceChildren(record.image);
      status.textContent = "";
    } catch {
      // A replaced preview must not clear a newer one.
      if (disposed || current !== record) return;

      releaseCurrent();
      status.textContent = "This image could not be previewed.";
    }
  }

  function dispose() {
    if (disposed) return;

    disposed = true;
    releaseCurrent();
    status.textContent = "";
  }

  return { show, dispose };
}

Connect it to the input:

const input = document.querySelector("#file");
const controller = createPreviewController(
  document.querySelector("#preview"),
  document.querySelector("#status"),
);

function onChange() {
  void controller.show(input.files?.[0]);
}

input.addEventListener("change", onChange);

// Call this when the upload view is removed.
function destroyUploadView() {
  input.removeEventListener("change", onChange);
  controller.dispose();
}

In a framework, destroyUploadView() belongs in the component’s teardown path.

Cleanup alone does not prevent stale results

The identity check after decode() is essential.

Imagine this sequence:

The user selects image A.
Decoding A starts.
The user selects image B.
Decoding B starts.
A’s asynchronous operation settles.

Without the identity check, A could replace B or display an error belonging to an obsolete selection.

Each operation captures its own record. It may update the interface only while that record remains current.

Revoking a URL is not a general-purpose cancellation mechanism for every operation already consuming it. Resource cleanup and stale-result protection solve different problems. This controller needs both.

Do not revoke immediately after assigning `src`

This is a race:

const url = URL.createObjectURL(file);
image.src = url;
URL.revokeObjectURL(url);

The browser may still need to resolve the URL.

Revoking after loading is more deliberate, but it can also interfere with later interactions that depend on the URL, such as opening the image separately.

A straightforward policy is to retain the URL while its preview remains available. Revoke it when the preview is replaced, removed, or disposed.

That makes the lifecycle predictable and easier to review.

Small thumbnails can still require large decodes

Fixing object URL leaks does not establish a memory budget.

A compressed image might occupy a few megabytes on disk while its decoded pixels require much more space. An 8,000 × 6,000 image represented as four bytes per pixel is approximately 183 MiB for one pixel buffer.

Actual browser memory usage varies, and additional buffers may exist.

Setting an image to width: 160px changes its displayed size. It does not guarantee that decoding will use only a thumbnail-sized buffer.

For a multi-file uploader, also limit how many previews are prepared concurrently. Render previews near the viewport, release those no longer needed, and avoid decoding an entire selection at once.

Generating smaller preview blobs can reduce retained preview costs. However, generating those thumbnails may itself require decoding the original. Measure that temporary peak too.

File validation is a separate boundary

The input’s accept attribute is a selection hint. It is not security validation.

Likewise, file.type can be missing or misleading. A successful browser preview does not prove that a file satisfies the application’s upload policy.

Apply independent server-side checks for supported formats, file size, and processing limits.

Never insert uploaded SVG markup directly into the page to create a preview. Treat user-provided content as untrusted, even when its filename ends in an image extension.

Test the lifecycle, not just the first preview

A useful manual test repeats the uncomfortable paths:

Replace a large image before its preview appears.
Remove a file while decoding is pending.
Select an unsupported or damaged image.
Leave the upload view while a preview is being prepared.
Repeat selection and removal dozens of times.

For automated tests, spy on object URL creation and revocation. After disposal, every created URL should have a matching revocation.

Do not expect the browser’s process memory to fall immediately after cleanup. Garbage collection, decoder caches, and allocation strategies affect what memory tools display.

The actionable failure is resources accumulating across repeated interactions. Explicit ownership makes those leaks easier to locate—and prevents an apparently harmless preview feature from consuming the whole session.

Strip EXIF and GPS Metadata in the Browser Before Uploading Photos

Edmond Rätzel — Mon, 14 Sep 2026 06:13:34 +0000

A user uploads a photo to your application. The image looks harmless, but the JPEG may contain much more than pixels: GPS coordinates, camera model, capture time, orientation data, editing software, and other EXIF metadata.
For a media-heavy SaaS, that can become a privacy problem surprisingly quickly.
You could strip metadata after the file reaches your backend, but there is another useful option: sanitize the image in the browser before the upload begins.
This is especially useful when the original metadata has no business value.
What Are We Actually Trying to Remove?
A typical JPEG can contain metadata such as:
GPS latitude and longitude
camera manufacturer and model
capture date
lens information
image orientation
editing software
copyright fields
embedded thumbnails
The simplest way to remove most of this metadata is not to parse every EXIF block individually.
Instead, decode the image into pixels and encode a completely new image.
The browser gives us the primitives to do that.
The basic pipeline looks like this:
Original file
↓
Decode image
↓
Draw pixels to canvas
↓
Encode new JPEG/WebP
↓
Upload sanitized Blob
The important detail is that the canvas contains pixel data, not the original JPEG metadata.
When we export the canvas, the browser creates a new image file.
A Minimal Implementation
Here is a small utility that accepts an uploaded image and returns a new JPEG blob:
async function sanitizeImage(file, quality = 0.9) {
const bitmap = await createImageBitmap(file);

const canvas = document.createElement("canvas");
canvas.width = bitmap.width;
canvas.height = bitmap.height;

const ctx = canvas.getContext("2d");

if (!ctx) {
throw new Error("Canvas 2D context is unavailable");
}

ctx.drawImage(bitmap, 0, 0);

bitmap.close();

return new Promise((resolve, reject) => {
canvas.toBlob(
blob => {
if (!blob) {
reject(new Error("Image encoding failed"));
return;
}

    resolve(blob);
  },
  "image/jpeg",
  quality
);

});
}
Usage:
const input = document.querySelector("#photo");

input.addEventListener("change", async event => {
const file = event.target.files?.[0];

if (!file) return;

const sanitized = await sanitizeImage(file);

console.log("Original:", file.size);
console.log("Sanitized:", sanitized.size);

await uploadFile(sanitized);
});
The resulting JPEG is created from decoded pixels instead of copying the original file byte-for-byte.
That distinction is what removes the original EXIF payload.
Keep the Filename and MIME Type Separate
A Blob does not have a filename. If your upload API expects a normal file object, wrap it in a File:
function blobToFile(blob, originalName) {
const baseName = originalName.replace(/.[^.]+$/, "");

return new File(
[blob],
${baseName}.jpg,
{
type: "image/jpeg",
lastModified: Date.now()
}
);
}
Then:
const cleanBlob = await sanitizeImage(originalFile);
const cleanFile = blobToFile(cleanBlob, originalFile.name);

await uploadFile(cleanFile);
Do not trust the original file extension to describe the newly encoded content.
If you converted a PNG or WebP to JPEG, update the filename accordingly.
Resizing at the Same Time
Once the image is being decoded anyway, this is also a convenient place to enforce upload dimensions.
A 9000×6000 photo does not need to become a 9000×6000 preview.
function fitInside(width, height, maxWidth, maxHeight) {
const scale = Math.min(
maxWidth / width,
maxHeight / height,
1
);

return {
width: Math.round(width * scale),
height: Math.round(height * scale)
};
}
Use it before drawing:
const size = fitInside(
bitmap.width,
bitmap.height,
3000,
3000
);

canvas.width = size.width;
canvas.height = size.height;

ctx.drawImage(
bitmap,
0,
0,
size.width,
size.height
);
Now one browser-side operation can both remove metadata and reduce unnecessarily large uploads.
That can significantly reduce network traffic for image-heavy applications.
Do Not Block the UI With Huge Images
Canvas operations are CPU- and memory-intensive.
A 50-megapixel image can require hundreds of megabytes of temporary memory once decoded.
Processing several images simultaneously is an easy way to freeze a browser tab.
Avoid this:
await Promise.all(
files.map(file => sanitizeImage(file))
);
For large uploads, use a small concurrency limit.
for (const file of files) {
const sanitized = await sanitizeImage(file);
await uploadFile(sanitized);
}
Sequential processing is slower, but much safer on mobile devices.
A more advanced implementation can process two or three images concurrently or move image work into workers where browser support permits.
Canvas Sanitization Is Not a Security Boundary
This technique is useful, but it should not replace server-side validation.
The backend should still verify:
MIME type
actual file signature
file size
image dimensions
authentication
authorization
storage path
upload ownership
Never assume that a browser-generated request came from your frontend code.
An attacker can bypass your JavaScript entirely and call the upload API directly.
Client-side sanitization improves privacy and efficiency. Server-side validation protects the system.
You normally want both.
Watch Out for Image Orientation
Older JPEG workflows often rely on EXIF orientation tags.
If metadata is removed incorrectly, portrait photos can suddenly appear rotated.
Modern browser decoding generally handles orientation before rendering, but this area has historically differed between APIs and browser versions.
Test uploads from actual phones, especially:
iPhones
Android devices
DSLR and mirrorless cameras
exported Lightroom files
Do not validate the pipeline using only images created on your development machine.
What About Original Downloads?
Sometimes removing metadata is exactly what you do not want.
A photography application might need two representations:
original.jpg
├── original download
└── sanitized web preview
That architecture lets you preserve the photographer's original file while exposing a metadata-free derivative to viewers.
It also avoids repeatedly transforming the original.
For systems with customer-facing galleries, this separation is usually cleaner than treating one file as both archival media and web delivery media.
Final Architecture
A practical upload flow can look like this:
User selects image
↓
Validate basic file type
↓
Decode image in browser
↓
Resize if necessary
↓
Re-encode without original metadata
↓
Upload sanitized derivative
↓
Server performs independent validation
↓
Store and deliver through media pipeline
Metadata privacy is easy to overlook because nothing looks wrong visually.
But location data and camera information can survive every UI redesign while quietly traveling with the file.
Treat metadata as part of your data model, not as an invisible property of an image.

Building Secure Auto-Resizing Iframe Embeds with postMessage

Edmond Rätzel — Fri, 04 Sep 2026 20:28:33 +0000

Embedding a dynamic web application inside an iframe sounds simple until the embedded page changes height.

A photo gallery loads more images. A comment panel opens. A video expands. A shop section becomes visible.

The iframe itself does not automatically tell the parent page that its content is now 2,000 pixels taller.

The usual first attempt is something like this:

<iframe
  src="https://embed.example.com/gallery/123"
  style="width:100%;height:800px"
></iframe>

That works until the content becomes shorter or taller.

Then you get scrollbars, large empty areas, clipped content, or a mobile layout that feels completely broken.

For cross-origin embeds, the parent page also cannot simply inspect the iframe DOM because of the browser's same-origin policy.

The right solution is usually a small messaging protocol built on window.postMessage().

Why direct DOM access fails

If the parent page and iframe are served from different origins, this is blocked:

const iframe = document.querySelector("iframe");

const height =
  iframe.contentWindow.document.body.scrollHeight;

For example:

Parent:
https://photographer.example

Iframe:
https://gallery.example

These are different origins.

That separation is intentional. Without it, any website could embed your banking dashboard and inspect its DOM.

So instead of reading the embedded page directly, the iframe must measure itself and explicitly send information to its parent.

Measure inside the iframe

The embedded application has full access to its own layout.

A simple implementation can measure the document height:

function getDocumentHeight() {
  return Math.max(
    document.body.scrollHeight,
    document.documentElement.scrollHeight
  );
}

Then send it to the parent:

window.parent.postMessage(
  {
    type: "embed:resize",
    height: getDocumentHeight()
  },
  "https://photographer.example"
);

The parent listens for the event:

window.addEventListener("message", event => {
  if (event.origin !== "https://gallery.example") {
    return;
  }

  const data = event.data;

  if (data?.type !== "embed:resize") {
    return;
  }

  const iframe = document.querySelector(
    '[data-gallery-embed="123"]'
  );

  iframe.style.height = `${data.height}px`;
});

This gives the parent exactly the information it needs without exposing the iframe DOM.

Do not use `"*"` as the target origin

You will often see examples like this:

window.parent.postMessage(
  {
    type: "embed:resize",
    height: 1200
  },
  "*"
);

It is convenient.

It is also unnecessarily broad.

If you know which parent origins are allowed to embed your application, send messages only to those origins.

Similarly, the parent should always validate:

event.origin

before trusting a message.

Without that check, another window could send a forged message such as:

{
  type: "embed:resize",
  height: 999999
}

and potentially disrupt your page layout.

For more sensitive message types, origin validation becomes even more important.

ResizeObserver is better than polling

A naive embed implementation might send the current height every second:

setInterval(() => {
  sendHeight();
}, 1000);

That works, but it is wasteful and can still feel delayed.

A better option is ResizeObserver.

const observer = new ResizeObserver(() => {
  sendHeight();
});

observer.observe(document.body);

Now the iframe reacts when its layout changes.

A complete version might look like this:

const parentOrigin =
  new URL(document.referrer).origin;

function sendHeight() {
  const height = Math.max(
    document.body.scrollHeight,
    document.documentElement.scrollHeight
  );

  window.parent.postMessage(
    {
      type: "embed:resize",
      height
    },
    parentOrigin
  );
}

const observer = new ResizeObserver(() => {
  sendHeight();
});

observer.observe(document.body);

window.addEventListener("load", sendHeight);

This catches both the initial layout and later changes.

Images create another timing problem

Media-heavy embeds often render before all images have loaded.

The first height might be:

620px

Then images appear and the real height becomes:

1840px

If image dimensions are not reserved in advance, the embedded page may resize repeatedly.

You should still use explicit image dimensions or aspect-ratio inside the iframe:

.gallery-image {
  width: 100%;
  aspect-ratio: 3 / 2;
  object-fit: cover;
}

That reduces layout instability and makes resize messages less noisy.

The embed protocol should not be used as a substitute for good internal layout behavior.

Add a message namespace

As your embed grows, resize messages are rarely the only thing crossing the iframe boundary.

You may eventually need:

embed:ready
embed:resize
embed:navigate
embed:checkout
embed:auth-expired

A predictable message schema helps:

type EmbedMessage =
  | {
      type: "embed:ready";
      version: 1;
    }
  | {
      type: "embed:resize";
      height: number;
    }
  | {
      type: "embed:navigate";
      path: string;
    };

Versioning is useful if customers keep old embed snippets on their websites for years.

Without versioning, changing message semantics later can break existing integrations.

Validate message payloads

Origin validation is only half the job.

Do not trust the payload either.

This is unsafe:

iframe.style.height =
  `${event.data.height}px`;

Validate the value:

const height = Number(event.data.height);

if (
  !Number.isFinite(height) ||
  height < 100 ||
  height > 20000
) {
  return;
}

iframe.style.height = `${height}px`;

The exact limits depend on your product, but bounded input is much safer than blindly applying whatever arrives.

Multiple embeds need unique identifiers

A page may contain several embedded galleries.

If every resize message just says:

{
  type: "embed:resize",
  height: 1200
}

the parent does not know which iframe sent it.

Include an embed ID:

window.parent.postMessage(
  {
    type: "embed:resize",
    embedId: "gallery_123",
    height: 1200
  },
  parentOrigin
);

Then resolve the correct element:

const iframe = document.querySelector(
  `[data-embed-id="${data.embedId}"]`
);

Even better, compare the source window:

if (event.source !== iframe.contentWindow) {
  return;
}

This prevents one embed from accidentally controlling another.

Avoid redirect surprises

Another subtle problem appears when the iframe navigates internally.

Suppose the embedded application redirects from:

https://gallery.example/embed/123

to:

https://auth.gallery.example/login

The origin has changed.

If your parent only accepts messages from:

https://gallery.example

the resize protocol suddenly stops working.

You should either keep embedded navigation on one origin or explicitly support every trusted origin involved in the flow.

Do not solve this by accepting every origin.

Use sandbox deliberately

If you control the embed snippet, consider an iframe sandbox policy:

<iframe
  src="https://gallery.example/embed/123"
  sandbox="
    allow-scripts
    allow-forms
    allow-same-origin
    allow-popups
  "
></iframe>

Only enable capabilities the embedded application actually needs.

Be careful with combinations such as:

allow-scripts
allow-same-origin

when embedding content from the same origin as the parent, because that can weaken the protection sandboxing was supposed to provide.

Cross-origin SaaS embeds are usually easier to reason about.

The protocol is the real integration surface

An iframe embed is not just a rectangle containing another website.

Once the embedded content needs to resize, report state, open checkout flows, or communicate navigation events, the boundary between parent and iframe becomes an API.

Treat it like one.

Define message types.

Validate origins.

Validate payloads.

Version the protocol.

Identify individual embeds.

Use browser observers instead of polling.

And keep authorization decisions on the server rather than trusting anything sent through postMessage.

With those pieces in place, a cross-origin iframe can behave like a native part of the host website without sacrificing the browser security boundary that made the iframe useful in the first place.

Building a Fast Responsive Image Grid Without Layout Shift

Edmond Rätzel — Fri, 28 Aug 2026 22:32:14 +0000

A gallery page contains 150 photos.

On a desktop connection it looks fine. Then you open it on a phone.

The page jumps while images load. Scrolling stutters. The browser downloads files much larger than the screen needs. Lazy loading helps a little, but the first several seconds still feel unstable.

Large image grids expose frontend performance problems very quickly.

The solution is not one optimization. You need layout stability, responsive image delivery, controlled lazy loading, and a rendering strategy that avoids making the browser process the entire gallery at once.

Reserve image space before the file arrives

One of the easiest ways to create layout shift is rendering an image without telling the browser its dimensions.

Consider:


html
<img src="/photos/portrait.jpg" alt="Portrait">
Until the image metadata arrives, the browser may not know how much vertical space it needs.
When the image loads, everything below it moves.
Instead, provide dimensions:
<img
  src="/photos/portrait.jpg"
  width="1600"
  height="1067"
  alt="Portrait"
>
The browser can calculate the aspect ratio immediately.
Modern CSS also makes this explicit:
.gallery-item {
  aspect-ratio: var(--ratio);
  overflow: hidden;
}

.gallery-item img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}
If image dimensions are already stored in your media metadata, generate the ratio server-side.
const ratio = `${image.width} / ${image.height}`;

return (
  <figure
    className="gallery-item"
    style={{ "--ratio": ratio }}
  >
    <img
      src={image.url}
      alt={image.alt}
      width={image.width}
      height={image.height}
    />
  </figure>
);
That metadata is more valuable than it looks. Width and height should ideally be extracted during upload processing rather than calculated in the browser.
Do not send desktop-sized images to phones
A responsive grid might display an image at 320 pixels wide on mobile and 700 pixels wide on desktop.
Sending a 3000-pixel image in both cases wastes bandwidth.
Use srcset:
<img
  src="/media/photo-800.webp"
  srcset="
    /media/photo-400.webp 400w,
    /media/photo-800.webp 800w,
    /media/photo-1200.webp 1200w,
    /media/photo-1600.webp 1600w
  "
  sizes="
    (max-width: 600px) 50vw,
    (max-width: 1200px) 33vw,
    25vw
  "
  width="1600"
  height="1067"
  alt="Wedding portrait"
>
The browser now chooses an appropriate resource based on viewport size and device pixel ratio.
This is usually better than selecting image sizes with JavaScript because the browser knows more about the current rendering environment.
Your image pipeline should therefore generate several variants when media is processed.
For example:
original.jpg
400.webp
800.webp
1200.webp
1600.webp
You may also generate AVIF versions when your infrastructure supports it efficiently.
Use modern formats without breaking fallback behavior
The <picture> element works well when you want multiple formats:
<picture>
  <source
    type="image/avif"
    srcset="
      /photo-400.avif 400w,
      /photo-800.avif 800w
    "
  >

  <source
    type="image/webp"
    srcset="
      /photo-400.webp 400w,
      /photo-800.webp 800w
    "
  >

  <img
    src="/photo-800.jpg"
    width="1600"
    height="1067"
    alt="Portrait"
  >
</picture>
The browser uses the first supported format.
This lets you improve transfer size without forcing format detection into application code.
One mistake is generating every possible format and dimension combination without considering storage and processing cost.
A media pipeline can easily explode into dozens of derived files per upload.
Choose a small number of useful breakpoints based on actual gallery layouts.
Lazy loading is useful, but not for everything
Native lazy loading is usually enough for images far below the fold:
<img
  src="/photo.webp"
  loading="lazy"
  width="1600"
  height="1067"
  alt="Portrait"
>
But do not blindly add loading="lazy" to every image.
The first visible images should load immediately.
For an important image near the top of the page, you can use:
<img
  src="/hero.webp"
  loading="eager"
  fetchpriority="high"
  width="2000"
  height="1200"
  alt="Gallery cover"
>
Overusing fetchpriority="high" is another common mistake.
If 20 images are high priority, none of them are meaningfully prioritized.
Reserve it for genuinely important above-the-fold content.
Avoid rendering hundreds of complex cards at once
Images are only part of the problem.
A gallery item may also contain:
favorite controls
comments
selection state
download buttons
price information
menus
hover effects
Rendering 300 full interactive cards at once can become expensive even if images are lazy-loaded.
One simple CSS optimization is content-visibility:
.gallery-item {
  content-visibility: auto;
  contain-intrinsic-size: 400px 300px;
}
This allows the browser to skip much of the rendering work for off-screen content.
For extremely large collections, virtualization may be appropriate, but photo grids make virtualization harder because item heights can vary.

Before adding a virtualization library, measure whether simpler containment and incremental rendering solve the problem.
Build the grid without JavaScript layout calculations
A basic responsive grid does not need JavaScript.
.gallery {
  display: grid;
  grid-template-columns:
    repeat(auto-fill, minmax(240px, 1fr));
  gap: 12px;
}
This adapts naturally to available width.
For more visually varied galleries, CSS columns can create a masonry-like layout:
.gallery {
  columns: 4 280px;
  column-gap: 12px;
}

.gallery-item {
  break-inside: avoid;
  margin-bottom: 12px;
}
Each approach has trade-offs.
CSS Grid gives predictable row structure. Columns produce a masonry-like appearance but alter visual ordering behavior.
Choose based on product requirements, not just appearance.
Cache derived images aggressively
Generated image variants are ideal CDN assets because they usually do not change.

Give immutable derived files versioned names:
photo_abc123_800.webp
Then use long-lived caching:
Cache-Control: public, max-age=31536000, immutable
If an image changes, create a new asset identifier instead of overwriting the old URL.

This makes browser and CDN caching much more effective.
Private media requires a different authorization strategy, but the underlying principle remains useful: avoid regenerating and retransferring identical derivatives unnecessarily.
Measure the actual gallery
Optimizing individual images is not enough.
Test realistic pages.
A gallery with six sample images may hide problems that become obvious with 200.
Measure:
Largest Contentful Paint
Cumulative Layout Shift
total transferred image bytes
number of image requests
main-thread rendering time
mobile scrolling performance
Also test slow mobile networks.

A layout that feels perfect on gigabit Wi-Fi can behave very differently on a constrained connection.
The best image grid does less work
Fast media interfaces usually come from reducing unnecessary work.
Reserve dimensions before images load.

Send files close to their rendered size.
Let the browser choose responsive resources.
Lazy-load content that is genuinely off-screen.
Avoid rendering complex UI before it is needed.
Cache immutable derivatives aggressively.

None of these techniques is particularly exotic.
But together they change a large photo gallery from a page that merely works into one that remains stable and responsive even when the media collection becomes large.

Building Resumable Browser Uploads That Survive Real-World Failures

Edmond Rätzel — Sun, 23 Aug 2026 19:34:28 +0000

A 4 GB video upload reaches 97%.

Then the user's Wi-Fi drops for five seconds.

If your upload implementation starts again from byte zero, you do not really have a large-file upload system. You have a very optimistic file transfer.

Reliable browser uploads need to assume that connections fail, tabs reload, requests time out, and clients occasionally send the same request twice.

The usual solution is chunked, resumable uploads. But splitting a file into pieces is only the beginning. The harder part is making retries safe and keeping client and server state synchronized.

Start with an upload session

Instead of sending the entire file directly, the client first asks the backend to create an upload session.

POST /uploads
Content-Type: application/json

{
  "filename": "project-final.mp4",
  "size": 4294967296,
  "contentType": "video/mp4"
}

The server returns an identifier and the chunk size it expects:

{
  "uploadId": "upl_7f91c2",
  "chunkSize": 8388608
}

Using a server-defined chunk size is useful because the backend can tune it without requiring frontend changes.

For example, 8 MB chunks provide a reasonable balance between request overhead and retry cost.

Slice the file in the browser

The browser does not need to load the entire file into memory.

File inherits from Blob, which means we can use slice():

const CHUNK_SIZE = 8 * 1024 * 1024;

function getChunk(file, index) {
  const start = index * CHUNK_SIZE;
  const end = Math.min(start + CHUNK_SIZE, file.size);

  return file.slice(start, end);
}

Then upload one chunk at a time:

async function uploadChunk(uploadId, index, chunk) {
  const response = await fetch(
    `/uploads/${uploadId}/chunks/${index}`,
    {
      method: "PUT",
      body: chunk
    }
  );

  if (!response.ok) {
    throw new Error(`Chunk ${index} failed`);
  }
}

Sequential uploads are simple and predictable. Once that works reliably, limited concurrency can improve throughput.

Do not jump immediately to uploading 20 chunks in parallel. On slower connections that can make performance worse rather than better.

Retries must be idempotent

The most important backend property is this:

Uploading chunk 17 twice should produce the same result as uploading it once.

Imagine the server successfully stores a chunk, but the response is lost before reaching the browser.

The client sees a timeout.

It has no idea whether the upload succeeded.

So it retries.

If your backend treats that retry as a completely new operation, corruption or duplicate data becomes possible.

A chunk endpoint should therefore behave idempotently:

PUT /uploads/upl_7f91c2/chunks/17

The identity of the operation is already encoded in the URL.

The backend can safely replace or confirm the existing chunk rather than append arbitrary bytes to a growing file.

This is much safer than a design where every request simply means "append these bytes."

Track completed chunks on the server

The browser should never be the only source of truth.

Store upload state such as:

{
  "uploadId": "upl_7f91c2",
  "status": "uploading",
  "totalChunks": 512,
  "completedChunks": [0, 1, 2, 3, 4, 6, 7]
}

Now a client can reload the page and ask:

GET /uploads/upl_7f91c2

The response tells it which chunks are already present.

const state = await fetch(
  `/uploads/${uploadId}`
).then(r => r.json());

const completed = new Set(state.completedChunks);

for (let i = 0; i < totalChunks; i++) {
  if (completed.has(i)) continue;

  await uploadChunk(
    uploadId,
    i,
    getChunk(file, i)
  );
}

There is one limitation here: after a full browser reload, the browser cannot silently regain access to the original local file.

The user may need to select it again.

You should therefore verify that the reselected file matches the original session before continuing.

Useful checks include filename, file size, modification timestamp, or a stronger fingerprint.

Never resume against a different file just because its name happens to match.

Progress should represent confirmed data

A misleading progress bar is worse than no progress bar.

Do not report progress merely because the browser has attempted to send chunks.

Track bytes that the server has confirmed.

function calculateProgress(
  completedChunks,
  chunkSize,
  fileSize
) {
  const uploaded = Math.min(
    completedChunks * chunkSize,
    fileSize
  );

  return Math.round(
    (uploaded / fileSize) * 100
  );
}

If you upload chunks concurrently, count each chunk only after its request succeeds.

That way a retry does not make the progress bar jump backward or accidentally exceed 100%.

Add bounded retry behavior

Networks fail. Retrying immediately in a tight loop is not a recovery strategy.

Use exponential backoff:

const delay = ms =>
  new Promise(resolve => setTimeout(resolve, ms));

async function withRetry(fn, maxAttempts = 5) {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (error) {
      if (attempt === maxAttempts) {
        throw error;
      }

      const wait =
        Math.min(1000 * 2 ** (attempt - 1), 10000);

      await delay(wait);
    }
  }
}

Then:

await withRetry(() =>
  uploadChunk(uploadId, index, chunk)
);

In production, adding random jitter is also useful so thousands of clients do not all retry at exactly the same moment after a temporary outage.

Do not trust chunk metadata from the client

A client may claim:

chunkIndex = 42

That does not mean the server should blindly accept it.

Validate:

the upload session exists
the session belongs to the authenticated user
the upload is still open
the chunk index is within range
the body is not larger than the configured chunk size
the declared total file size is within account limits

If your system uses object storage, upload permissions should also be scoped to one specific upload session rather than granting broad write access to a bucket.

Finalization should be explicit

Uploading the final chunk should not automatically mean the file is ready.

Use a separate completion step:

POST /uploads/upl_7f91c2/complete

The backend can then verify that every required chunk exists.

Only after validation should the upload move into a state such as:

uploading
→ assembling
→ processing
→ ready

For media systems, "uploaded" and "ready" are often very different states.

A video may still require metadata extraction, thumbnail generation, transcoding, or validation before users should see it.

Clean up abandoned sessions

Resumable uploads create temporary state.

Some users will never finish.

Without cleanup, incomplete chunks eventually become an expensive pile of orphaned storage.

Store an expiration time with every upload session and periodically delete sessions that have not been touched for a reasonable period.

Do not make the timeout too aggressive. A multi-gigabyte upload on a slow connection can legitimately take hours.

The architecture matters more than the progress bar

Large-file uploading looks like a frontend feature, but most reliability problems are architectural.

The browser should be able to retry.

The server should make retries harmless.

Upload progress should come from confirmed state.

Finalization should validate completeness.

And temporary data should have an explicit lifecycle.

Once those pieces are in place, a failed request becomes boring.

That is exactly what you want.

The user reconnects, the client checks what already arrived, and the upload continues instead of throwing away gigabytes of completed work.

Private Video Delivery Without Breaking Seeking: Signed URLs, Range Requests, and Expiry

Edmond Rätzel — Tue, 18 Aug 2026 12:33:47 +0000

A private video works perfectly when you press play.

Then you drag the timeline to 12:43.

The player spins for a few seconds and fails.

This is a common problem when building authenticated video delivery. The application correctly protects the original file, but the implementation assumes that playing a video is equivalent to downloading one file in one HTTP request.

Browsers do not necessarily work that way.

Video players often request small byte ranges from different parts of the file. Seeking, buffering, reconnecting, and switching playback position can all generate additional HTTP requests.

If authentication, signed URLs, caching, and range handling are not designed together, private video playback becomes unreliable surprisingly quickly.

Why video players use range requests

Suppose a browser wants only bytes 5,000,000 through 7,000,000 of a video.

It may send:

GET /media/video.mp4
Range: bytes=5000000-7000000

A range-aware server should respond with 206 Partial Content rather than 200 OK:

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 5000000-7000000/94837522
Content-Length: 2000001
Content-Type: video/mp4

The browser can then fetch only the portion it needs.

That makes seeking fast and avoids downloading a 500 MB video just because somebody wants to watch the final 30 seconds.

For large media applications, preserving this behavior is essential.

Do not stream private files through the application server

A tempting architecture looks like this:

Browser
  ↓
Application server
  ↓
Object storage

The application authenticates the user, reads the video from storage, and sends the bytes back.

It works.

It also turns the application server into an expensive media proxy.

A better architecture is usually:

Browser
  ↓
Application API
  ↓
Authorization check
  ↓
Short-lived media authorization
  ↓
CDN
  ↓
Object storage

Your application decides who may access the video.

Your CDN and object storage handle moving the bytes.

Those are different responsibilities and separating them makes scaling much easier.

Sign access to a specific resource

One simple approach is to create a short-lived token containing the media path and expiry.

For example:

import crypto from "node:crypto";

const SECRET = process.env.MEDIA_SIGNING_SECRET;

function signMediaPath(path, expiresAt) {
  const payload = `${path}:${expiresAt}`;

  return crypto
    .createHmac("sha256", SECRET)
    .update(payload)
    .digest("hex");
}

You could generate a playback URL such as:

const path = "/private/videos/8f32b1.mp4";
const expires = Math.floor(Date.now() / 1000) + 3600;
const signature = signMediaPath(path, expires);

const url =
  `${path}?expires=${expires}&signature=${signature}`;

At the edge or media endpoint, validate both values:

function verifyMediaRequest(path, expires, signature) {
  if (Number(expires) < Math.floor(Date.now() / 1000)) {
    return false;
  }

  const expected = signMediaPath(path, expires);

  const a = Buffer.from(expected);
  const b = Buffer.from(signature);

  if (a.length !== b.length) {
    return false;
  }

  return crypto.timingSafeEqual(a, b);
}

The important detail is that the signature covers the resource path.

A token created for:

/private/videos/a.mp4

must not also authorize:

/private/videos/b.mp4

Otherwise a user may be able to modify the path while reusing a valid token.

Expiry gets tricky during playback

Very short-lived signed URLs sound more secure.

For images, a five-minute expiration might be perfectly reasonable.

For a 90-minute video, it may cause problems.

The browser can begin playback while the token is valid and make another range request 20 minutes later. If authorization is checked again and the token expired after five minutes, seeking or buffering may suddenly fail.

There are several ways to handle this.

One is simply making playback authorization long enough to cover a reasonable viewing session.

Another is using a renewable playback session. Your application issues a media credential, the frontend refreshes it before expiry, and later range requests use the refreshed authorization.

Some CDN systems also support signed cookies or equivalent session-based authorization. That can work particularly well because the media URL itself does not need to change every time credentials are refreshed.

The right implementation depends on your infrastructure.

The important point is this:

Token lifetime should be designed around browser playback behavior, not just around the initial page request.

Preserve the Range header

Another easy mistake happens when a reverse proxy or CDN sits in front of storage.

The browser sends:

Range: bytes=20000000-

but an intermediate service removes the Range header.

The origin then returns the entire video.

Playback may still appear to work, making the bug harder to notice, but seeking becomes slower and bandwidth usage increases dramatically.

Check that your delivery chain correctly forwards and caches:

Range
If-Range
Content-Range
Accept-Ranges

Then test actual seeking in browser developer tools rather than checking only whether the video starts.

Keep playback and download permissions separate

A user being allowed to watch a video does not necessarily mean they should receive a convenient permanent download URL.

Model those permissions separately.

For example:

{
  mediaId: "video_123",
  canView: true,
  canDownload: false
}

Playback authorization can produce access suitable for browser streaming.

Explicit downloads can go through another authorization path.

This is especially useful in systems where gallery owners can independently enable viewing and downloading.

Do not rely on hiding a download button as access control. If the browser can retrieve a resource, users can inspect network traffic. Security has to exist at the delivery layer.

Be careful with CDN caching

Signed URLs also interact with caching.

If every request includes a unique signature:

video.mp4?signature=abc
video.mp4?signature=def
video.mp4?signature=ghi

and the CDN includes the complete query string in its cache key, the same video may be cached repeatedly.

That destroys much of the benefit of using a CDN.

Depending on the CDN, you may be able to validate authorization parameters while excluding them from the underlying object cache key.

The goal is:

Authorization: per request
Cached media object: shared

not:

Authorization: per request
Cached media object: duplicated per token

This becomes particularly important with large video files.

Test the failure cases

Before considering private video delivery finished, test more than pressing play.

Try:

seeking before the video has buffered
seeking near the end of a large file
refreshing after the token expires
opening an expired media URL directly
modifying the media path while keeping the signature
disabling download permission while retaining playback permission
loading several videos concurrently
testing through the production CDN rather than only localhost

Media delivery tends to expose assumptions that normal API requests never reveal.

The underlying architecture is fairly simple once the responsibilities are separated: the application handles authorization, the CDN handles delivery, object storage holds the original media, and HTTP range requests remain intact throughout the path.

Getting those boundaries right produces private video playback that is both secure and fast without turning the application server into a video streaming service.

How to Build Responsive Cross-Origin iframe Embeds

Edmond Rätzel — Mon, 10 Aug 2026 16:28:02 +0000

Embedding an external web app with an iframe is easy until the content inside starts changing height.

A fixed height usually creates one of two problems: too much empty space or an unwanted scrollbar.

For cross-origin iframes, the parent page cannot simply read the height of the embedded document because of the browser's same-origin policy.

A clean solution is to combine ResizeObserver with postMessage.

Inside the embedded page

The embedded application measures its own height and sends it to the parent:

function sendHeight() {
  window.parent.postMessage(
    {
      type: "iframe-resize",
      height: document.documentElement.scrollHeight
    },
    "https://example.com"
  );
}

const observer = new ResizeObserver(sendHeight);

observer.observe(document.documentElement);

window.addEventListener("load", sendHeight);

ResizeObserver is useful because the height can change after the initial page load.

For example:

images may load later
accordions may open
responsive layouts may change
dynamic content may be added
fonts may affect the layout

Instead of guessing a height, the iframe reports its actual size whenever something changes.

On the parent page

The parent listens for the message and updates the iframe:

const iframe = document.querySelector("#embedded-app");

window.addEventListener("message", (event) => {
  if (event.origin !== "https://embedded.example.com") {
    return;
  }

  if (event.data?.type !== "iframe-resize") {
    return;
  }

  const height = Number(event.data.height);

  if (!Number.isFinite(height) || height <= 0) {
    return;
  }

  iframe.style.height = `${height}px`;
});

The iframe itself can stay simple:

<iframe
  id="embedded-app"
  src="https://embedded.example.com"
  style="width: 100%; border: 0;"
></iframe>

Now the embedded content can grow or shrink without introducing an internal scrollbar.

Validate the origin

A common shortcut is:

window.parent.postMessage(data, "*");

That works, but it is better to specify the expected origin whenever possible.

The receiving page should also validate event.origin.

Treat messages coming from an iframe like any other external input: verify where they came from before using the data.

The result

This pattern keeps responsibilities clean:

the embedded app knows its own content height
the parent controls the iframe element
postMessage connects both sides safely
ResizeObserver reacts to layout changes

It is a simple approach, but it solves one of the most common problems with responsive cross-origin embeds without relying on arbitrary fixed heights.

DEV Community: Edmond Rätzel

Stop Proxying Large Media Uploads Through Your App Server

The problem with proxying uploads

Why multipart uploads matter

Step 1: Initialize the upload on the server

Step 2: Split the file in the browser

Step 3: Request signed URLs

Add concurrency, but not too much

Retry individual chunks

Track progress from bytes, not part counts

Step 4: Complete the upload

Do not forget abandoned uploads

Security still belongs on the server

The architecture scales better because the backend does less

Your Image Preview Is a Memory Leak: Managing Blob URLs in Long-Lived Web Apps

A blob URL is a resource handle

Make the preview own its resources

Cleanup alone does not prevent stale results

Do not revoke immediately after assigning src

Small thumbnails can still require large decodes

File validation is a separate boundary

Test the lifecycle, not just the first preview

Strip EXIF and GPS Metadata in the Browser Before Uploading Photos

Building Secure Auto-Resizing Iframe Embeds with postMessage

Why direct DOM access fails

Measure inside the iframe

Do not use "*" as the target origin

ResizeObserver is better than polling

Images create another timing problem

Add a message namespace

Validate message payloads

Multiple embeds need unique identifiers

Avoid redirect surprises

Use sandbox deliberately

The protocol is the real integration surface

Building a Fast Responsive Image Grid Without Layout Shift

Reserve image space before the file arrives

Building Resumable Browser Uploads That Survive Real-World Failures

Start with an upload session

Slice the file in the browser

Retries must be idempotent

Track completed chunks on the server

Progress should represent confirmed data

Add bounded retry behavior

Do not trust chunk metadata from the client

Finalization should be explicit

Clean up abandoned sessions

The architecture matters more than the progress bar

Private Video Delivery Without Breaking Seeking: Signed URLs, Range Requests, and Expiry

Why video players use range requests

Do not stream private files through the application server

Sign access to a specific resource

Expiry gets tricky during playback

Preserve the Range header

Keep playback and download permissions separate

Be careful with CDN caching

Test the failure cases

How to Build Responsive Cross-Origin iframe Embeds

Inside the embedded page

On the parent page

Validate the origin

The result

Do not revoke immediately after assigning `src`

Do not use `"*"` as the target origin