recursal/MDN huggingface dataset:
Permissions-Policy: document-domain
===================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

 The HTTP `Permissions-Policy` header
 `document-domain` directive controls whether the current document is
 allowed to set `document.domain`.

 Specifically, where a defined policy blocks use of this feature, attempting
 to set `document.domain` will fail and cause a `SecurityError`
`DOMException` to be thrown.

Syntax
------


```http
Permissions-Policy: document-domain=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `document-domain` is `*`.

Specifications
--------------

| Specification |
| --- |
| HTML Standard # policy-controlled-features |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: fullscreen
==============================

The HTTP `Permissions-Policy` header `fullscreen` directive controls whether the current document is allowed to use `Element.requestFullscreen()`.

By default, top-level documents and their same-origin child frames can request and enter fullscreen mode. This directive allows or prevents cross-origin frames from using fullscreen mode. This includes same-origin frames.

Specifically, where a defined policy blocks use of this feature, `requestFullscreen()` calls will return a `Promise` that rejects with a `TypeError`.

**Note:** If both this directive (i.e. via the `allow` attribute) and the `allowfullscreen` attribute are present on an `<iframe>` element, this directive takes precedence.

Syntax
------


```http
Permissions-Policy: fullscreen=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `fullscreen` is `self`.

Examples
--------

### General example

SecureCorp Inc. wants to disable the Fullscreen API within all browsing contexts except for its own origin and those whose origin is `https://example.com`. It can do so by delivering the following HTTP response header to define a Permissions Policy:


```http
Permissions-Policy: fullscreen=(self "https://example.com")
```

### With an <iframe> element

FastCorp Inc. wants to disable `fullscreen` for all cross-origin child frames, except for a specific `<iframe>`. It can do so by delivering the following HTTP response header to define a Permissions Policy:


```http
Permissions-Policy: fullscreen=(self)
```


Then include an allow attribute on the `<iframe>` element:


```html
<iframe src="https://other.com/videoplayer" allow="fullscreen"></iframe>
```


iframe attributes can selectively enable features in certain frames, and not in others, even if those frames contain documents from the same origin.

Specifications
--------------

| Specification |
| --- |
| Fullscreen API Standard # permissions-policy-integration |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: storage-access
==================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `storage-access` directive controls whether a document loaded in a third-party context (i.e. embedded in an `<iframe>`) is allowed to use the Storage Access API to request access to unpartitioned cookies.

This is relevant to user agents that by default block access to unpartitioned cookies by sites loaded in a third-party context to improve privacy (for example, to prevent tracking).

Specifically, where a defined policy blocks use of this feature, `Document.requestStorageAccess()` calls will return a `Promise` that rejects with a `DOMException` of type `NotAllowedError`.

Syntax
------


```http
Permissions-Policy: storage-access=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `storage-access` is `*`.

Specifications
--------------

| Specification |
| --- |
| The Storage Access API # permissions-policy-integration |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Storage Access API
* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: encrypted-media
===================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `encrypted-media` directive controls whether the current document is allowed to use the Encrypted Media Extensions API (EME).

Specifically, where a defined policy blocks use of this feature, the `Promise` returned by `Navigator.requestMediaKeySystemAccess()` will reject with a `DOMException` of type `SecurityError`.

Syntax
------


```http
Permissions-Policy: encrypted-media=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `encrypted-media` is `self`.

Specifications
--------------

| Specification |
| --- |
| Encrypted Media Extensions # permissions-policy-integration |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: gyroscope
=============================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `gyroscope` directive controls whether the current document is allowed to gather information about the orientation of the device through the `Gyroscope` interface.

Specifically, where a defined policy blocks use of this feature, `Gyroscope()` constructor calls will throw a `DOMException` of type `SecurityError`.

Syntax
------


```http
Permissions-Policy: gyroscope=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `gyroscope` is `self`.

Specifications
--------------

| Specification |
| --- |
| Generic Sensor API # permissions-policy |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: gamepad
===========================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `gamepad` directive controls whether the current document is allowed to use the Gamepad API.

Specifically, where a defined policy blocks use of this feature, calls to `Navigator.getGamepads()` will throw a `SecurityError` `DOMException`. In addition, the `gamepadconnected` and `gamepaddisconnected` events will not fire.

Syntax
------


```http
Permissions-Policy: gamepad=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `gamepad` is `self`.

Examples
--------

### General example

 SecureCorp Inc. wants to disable the Gamepad API within all browsing contexts except for its own origin and those whose origin is `https://example.com`.
 It can do so by delivering the following HTTP response header to define a Permissions Policy:


```http
Permissions-Policy: gamepad=(self "https://example.com")
```

### With an <iframe> element

 FastCorp Inc. wants to disable `gamepad` for all cross-origin child frames, except for a specific `<iframe>`.
 It can do so by delivering the following HTTP response header to define a Permissions Policy:


```http
Permissions-Policy: gamepad=(self)
```


Then include an allow attribute on the `<iframe>` element:


```html
<iframe src="https://other.com/game" allow="gamepad"></iframe>
```


iframe attributes can selectively enable features in certain frames, and not in others, even if those frames contain documents from the same origin.

Specifications
--------------

| Specification |
| --- |
| Gamepad # permission-policy |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: hid
=======================

Limited availability
--------------------

This feature is not Baseline because it does not work in some of the most widely-used browsers.

* Learn more
* See full compatibility
* Report feedback
**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `hid` directive controls whether the current document is allowed to use the WebHID API to connect to uncommon or exotic human interface devices such as alternative keyboards or gamepads.

Specifically, where a defined policy blocks WebHID usage, the `Navigator.hid` property will not be available.

Syntax
------


```http
Permissions-Policy: hid=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `hid` is `self`.

Specifications
--------------

| Specification |
| --- |
| WebHID API # permissions-policy |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: xr-spatial-tracking
=======================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `xr-spatial-tracking` directive controls whether the current document is allowed to use the WebXR Device API.

Specifically, where a defined policy blocks usage of this feature:

* `navigator.xr.isSessionSupported()` and `navigator.xr.requestSession()` calls will return a `Promise` that rejects with a `DOMException` of type `SecurityError`.
* `devicechange` events are not fired on the `navigator.xr` object.
Syntax
------


```http
Permissions-Policy: xr-spatial-tracking=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `xr-spatial-tracking` is `self`.

Specifications
--------------

| Specification |
| --- |
| WebXR Device API # permissions-policy |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* WebXR Device API
* `navigator.xr.requestSession()`, and `navigator.xr.isSessionSupported()` and `devicechange` event on `navigator.xr`
* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: picture-in-picture
======================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `picture-in-picture` directive controls whether the current document is allowed to play a video in a Picture-in-Picture mode.

Specifically, where a defined policy blocks use of this feature, `HTMLVideoElement.requestPictureInPicture()` calls will throw a `DOMException` of type `SecurityError`.

Syntax
------


```http
Permissions-Policy: picture-in-picture=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `picture-in-picture` is `*`.

Specifications
--------------

| Specification |
| --- |
| Picture-in-Picture # permissions-policy |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: payment
===========================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header field's `payment` directive controls whether the current document is allowed to use the Payment Request API.

Specifically, where a defined policy blocks use of this feature, `PaymentRequest()` constructor calls will throw a `DOMException` of type `SecurityError`.

Syntax
------


```http
Permissions-Policy: payment=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `payment` is `self`.

Specifications
--------------

| Specification |
| --- |
| Payment Request API 1.1 # permissions-policy |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header field
* Permissions Policy
Permissions-Policy: speaker-selection
=====================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `speaker-selection` directive controls whether the current document is allowed to enumerate and select audio output devices (speakers, headphones, and so on).

Specifically, where a defined policy blocks use of this feature:

* `MediaDevices.enumerateDevices()` won't return devices of type *audio output*.
* `MediaDevices.selectAudioOutput()` won't display the popup for selecting an audio output, and the returned `Promise` will reject with a `DOMException` of type `NotAllowedError`.
* `HTMLMediaElement.setSinkId()` and `AudioContext.setSinkId()` will throw a `NotAllowedError` if called for an audio output.
Syntax
------


```http
Permissions-Policy: speaker-selection=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `speaker-selection` is `self`.

Specifications
--------------

| Specification |
| --- |
| Audio Output Devices API # permissions-policy-integration |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: accelerometer
=================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `accelerometer` directive controls whether the current document is allowed to gather information about the acceleration of the device through the `Accelerometer` interface.

Specifically, where a defined policy blocks use of this feature, `Accelerometer()` constructor calls will throw a `DOMException` of type `SecurityError`.

Syntax
------


```http
Permissions-Policy: accelerometer=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `accelerometer` is: `self`.

Specifications
--------------

| Specification |
| --- |
| Generic Sensor API # permissions-policy |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: midi
========================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `midi` directive controls whether the current document is allowed to use the Web MIDI API.

Specifically, where a defined policy blocks use of this feature, `Navigator.requestMIDIAccess()` calls will return a `Promise` that rejects with a `DOMException` of type `SecurityError`.

Syntax
------


```http
Permissions-Policy: midi=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `midi` is `self`.

Specifications
--------------

| Specification |
| --- |
| Web MIDI API # permissions-policy-integration |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: usb
=======================

Limited availability
--------------------

This feature is not Baseline because it does not work in some of the most widely-used browsers.

* Learn more
* See full compatibility
* Report feedback
**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `usb` directive controls whether the current document is allowed to use the WebUSB API.

Specifically, where a defined policy blocks WebHID usage, the `Navigator.usb` property will not be available.

Syntax
------


```http
Permissions-Policy: usb=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `usb` is `self`.

Specifications
--------------

| Specification |
| --- |
| WebUSB API # permissions-policy |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: otp-credentials
===================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `otp-credentials` directive controls whether the current document is allowed to use the WebOTP API to request a one-time password (OTP) from a specially-formatted SMS message sent by the app's server, i.e., via `navigator.credentials.get({otp: ..., ...})`.

Specifically, where a defined policy blocks the use of this feature, the `Promise` returned by `navigator.credentials.get({otp})` will reject with a `SecurityError` `DOMException`.

Syntax
------


```http
Permissions-Policy: otp-credentials=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `otp-credentials` is `self`.

Specifications
--------------

| Specification |
| --- |
| WebOTP API # sctn-permissions-policy |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
* WebOTP API
* `OTPCredential` interface
Permissions-Policy: execution-while-not-rendered
================================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `execution-while-not-rendered` directive controls whether tasks should execute in frames while they're not being rendered (e.g. if an iframe is `hidden` or has `display: none` set).

Specifically, where a defined policy blocks execution of task rendering while content is not being rendered, while that condition is true, that content will be put in the frozen state as defined in the Page Lifecycle API. This stops execution of freezable tasks such as JavaScript timers (e.g. `setTimeout()`) and `fetch()` callbacks.

Syntax
------


```http
Permissions-Policy: execution-while-not-rendered=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `execution-while-not-rendered` is `*`.

Specifications
--------------

| Specification |
| --- |
| Page Lifecycle # feature-policies |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy
Permissions-Policy: serial
==========================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `serial` directive controls whether the current document is allowed to use the Web Serial API to communicate with serial devices, either directly connected via a serial port, or via USB or Bluetooth devices emulating a serial port.

Specifically, where a defined policy blocks use of this feature, `Serial.requestPort()` and `Serial.getPorts()` calls will return a `Promise` that rejects with a `DOMException` of type `SecurityError`.

Syntax
------


```http
Permissions-Policy: serial=<allowlist>;
```


`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `serial` is `self`.

Specifications
--------------

| Specification |
| --- |
| Web Serial API # permissions-policy |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Permissions-Policy` header
* Permissions Policy