Configuring Clipboard API Access Within an Iframe

Overview

To ensure the Clipboard API (reading/writing to the clipboard) and other browser interfaces function correctly within nested contexts (<iframe>), a permission policy must be configured across multiple levels.

1. The `allow` Attribute (HTML Permissions Policy)

When initializing an iframe, you must explicitly delegate access rights to the child resource using the allow attribute. Without this, the browser will block API calls for security reasons, especially in cross-origin scenarios.

<iframe
  src="https://example.com"
  allow="clipboard-read; clipboard-write; microphone; camera; display-capture; fullscreen"
></iframe>

Key Directives:

Directive	Description	Browser Support
`clipboard-read`	Access to read from the asynchronous clipboard	Chromium only
`clipboard-write`	Access to write to the asynchronous clipboard	Chromium only
`microphone`	Access to multimedia input devices (microphone)	All major browsers
`camera`	Access to multimedia input devices (camera)	All major browsers
`fullscreen`	Permission to toggle full-screen mode	All major browsers
`display-capture`	Permission to capture screen content	Experimental, limited support

⚠️
Browser compatibility: The clipboard-read and clipboard-write directives are recognized only by Chromium-based browsers (Chrome, Edge, Opera). Firefox and Safari do not support them and have no plans to. In those browsers, clipboard access inside iframes relies on transient user activation and paste prompts instead.

2. The `Permissions-Policy` HTTP Header

If the parent page or the embedded resource sends a Permissions-Policy header, it works in combination with the HTML allow attribute — not as an override. The browser applies the intersection of both policies: a feature must be allowed by both the HTTP header and the allow attribute to be available.

Example of a valid header configuration:

Permissions-Policy: clipboard-read=(self "https://example.com"), clipboard-write=(self "https://example.com"), microphone=*

Value	Meaning
`self`	Grants access to the current origin
`"https://example.com"`	Grants access to a specific domain within the iframe
`*`	Grants access to all origins (use with caution)

⚠️
The HTTP header and allow attribute are combined using the most restrictive rule. If the HTTP header blocks a feature, the allow attribute cannot re-enable it — and vice versa. Make sure both are aligned.

⚠️
Note that clipboard-read and clipboard-write as Permissions-Policy directives are a Chromium-specific extension. They are not part of the standardized directive set on MDN.

3. Secure Context Requirements

The Clipboard API and media device access operate strictly within a Secure Context:

HTTPS: Both the parent resource and the iframe must be served over HTTPS. Exceptions: localhost and file:// URLs are considered potentially trustworthy. Even if the iframe is served over HTTPS, its context is not secure if any ancestor in the frame chain was loaded over plain HTTP.
User Gesture (Transient User Activation): Writing to or reading from the clipboard must be triggered by a user action (e.g., a click or keypress). Programmatic "background" calls will be rejected by the browser. Note: in Chromium, once the user grants clipboard permission via the browser prompt, subsequent operations no longer require a user gesture for the duration of the session.

Quick Checklist

The <iframe> tag includes the allow attribute with the required directives
The parent page server does not send a restrictive Permissions-Policy header (or explicitly allows the needed directives)
Both parent page and iframe are served over HTTPS
Clipboard operations are triggered by user gestures (click, keypress)
Chromium-only features (clipboard-read/clipboard-write directives) are understood; alternative behavior in Firefox/Safari is accounted for

Configuring Clipboard API Access Within an Iframe

Overview

1. The `allow` Attribute (HTML Permissions Policy)

2. The `Permissions-Policy` HTTP Header

The HTTP header and `allow` attribute are combined using the most restrictive rule. If the HTTP header blocks a feature, the `allow` attribute cannot re-enable it — and vice versa. Make sure both are aligned.

Note that `clipboard-read` and `clipboard-write` as Permissions-Policy directives are a Chromium-specific extension. They are not part of the standardized directive set on MDN.

3. Secure Context Requirements

Quick Checklist

Overview

1. The allow Attribute (HTML Permissions Policy)

2. The Permissions-Policy HTTP Header

The HTTP header and allow attribute are combined using the most restrictive rule. If the HTTP header blocks a feature, the allow attribute cannot re-enable it — and vice versa. Make sure both are aligned.

Note that clipboard-read and clipboard-write as Permissions-Policy directives are a Chromium-specific extension. They are not part of the standardized directive set on MDN.

3. Secure Context Requirements

Quick Checklist

1. The `allow` Attribute (HTML Permissions Policy)

2. The `Permissions-Policy` HTTP Header

The HTTP header and `allow` attribute are combined using the most restrictive rule. If the HTTP header blocks a feature, the `allow` attribute cannot re-enable it — and vice versa. Make sure both are aligned.

Note that `clipboard-read` and `clipboard-write` as Permissions-Policy directives are a Chromium-specific extension. They are not part of the standardized directive set on MDN.