---
title: Configuring Clipboard API Access Within an Iframe
updatedAt: 2026-04-10T13:07:25.000Z
---

Fetch the complete documentation index at: https://docs.watchers.io/llms.txt

# Configuring Clipboard API Access Within an Iframe

How to configure permissions for Clipboard API, microphone, camera, and other browser interfaces inside 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.

```html
<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:

```http
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:

1. **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.

2. **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