Device Posture API W3C Candidate Recommendation Draft 20 May 2026 More details about this document This version: https://www.w3.org/TR/2026/CRD-device-posture-20260520/ Latest published version: https://www.w3.org/TR/device-posture/ Latest editor's draft: https://w3c.github.io/device-posture/ History: https://www.w3.org/standards/history/device-posture/ Commit history Test suite: https://wpt.live/device-posture Implementation report: https://wpt.fyi/results/device-posture Editors: Kenneth Rohde Christiansen ( Intel Corporation ) Alexis Menard ( Intel Corporation ) Former editor: Diego González ( Microsoft, formerly on behalf of Samsung ) Feedback: GitHub w3c/device-posture ( pull requests , new issue , open issues ) Additional resources Explainer Polyfill Copyright © 2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply. Abstract This document specifies an API that allows web applications to request and be notified of changes of the posture of a device. Status of This Document This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index . This specification is implemented in Chromium-based browsers. WebKit and Mozilla have not yet published formal positions on this specification. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation phase should subscribe to the repository on GitHub and take part in the discussions. This document was published by the Devices and Sensors Working Group as a Candidate Recommendation Draft using the Recommendation track . Publication as a Candidate Recommendation does not imply endorsement by W3C and its Members. A Candidate Recommendation Draft integrates changes from the previous Candidate Recommendation that the Working Group intends to include in a subsequent Candidate Recommendation Snapshot. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress. This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy . This document is governed by the 18 August 2025 W3C Process Document . Table of Contents Abstract Status of This Document 1. Introduction 2. Extensions to the Document interface 3. Extensions to the Navigator interface 4. The DevicePosture interface 4.1 The type attribute: Get current device posture 4.2 The onchange attribute: Handle posture changes 5. Posture types 6. Device Posture Media Queries 6.1 The device-posture media feature 7. Reading the posture 7.1 Posture values table 7.1.1 Foldables 8. Algorithms 8.1 Calculating the device posture information 8.2 Device Posture change 9. Security considerations 10. Privacy considerations 10.1 Types of privacy threats 10.1.1 Identifying users across contexts 10.1.2 Cross-origin iframes 10.1.3 Malicious script injection (for advertising or exploitation) 10.2 Mitigation strategies 10.2.1 Data minimization 10.2.2 User attention 10.2.3 User-mediated action 11. Accessibility considerations 12. Automation 12.1 Extension Commands 12.1.1 Set device posture 12.1.2 Clear device posture 13. Examples 13.1 Example 1: Posture data 13.2 Example 2: device-posture 13.3 Example 3: Feature detection of device-posture media feature 14. Conformance A. IDL Index B. Acknowledgments C. Summary of substantive changes C.1 Changes since the First Public Working Draft (2020/12/17) D. References D.1 Normative references D.2 Informative references 1. Introduction The device posture is the physical position in which a device holds which may be derived from sensors in addition to the angle. New types of mobile devices are appearing that have some sort of capabilities that allow them to change their posture. The most common types of devices are the ones that can fold (their screen or around their screen), allowing them to physically alter their form factor. The main interest in knowing the posture of a device is to enable new user experiences with responsive design. Among the described "folding" devices, there are mainly two different physical form factors: devices with a single flexible screen (seamless), and devices with two screens (with seam). They can both fold around a hinge, and the current specification applies to both types. It should be clarified as well that both seamless and (devices) with seam can be of different dimension ranging from mobile and tablets to laptop sizes. It should also be noted that different devices will have different default orientations (portrait or landscape), and that the fold might happen in a vertical or horizontal way. From enhancing the usability of a website by avoiding the area of a fold, to enabling innovative use cases for the web, knowing the posture of a device can help developers tailor their content to different devices. Content can be consumed and browsed even when the device is not flat, in which case the developer might want to provide a different layout for it depending on the posture state in which the device is being used. 2. Extensions to the Document interface The following internal slots are added to the Document interface. Internal slot Description [[CurrentPosture]] The device's current posture . 3. Extensions to the Navigator interface The [ HTML ] specification defines the Navigator interface, which this specification extends: WebIDL [ SecureContext , Exposed =(Window) ] partial interface Navigator { [ SameObject ] readonly attribute DevicePosture devicePosture ; }; 4. The DevicePosture interface WebIDL [ SecureContext , Exposed =(Window) ] interface DevicePosture : EventTarget { readonly attribute DevicePostureType type ; attribute EventHandler onchange ; }; enum DevicePostureType { " continuous " , " folded " }; 4.1 The type attribute: Get current device posture When getting the type attribute, the user agent MUST return the value of this 's relevant global object 's associated Document 's internal slot [[CurrentPosture]] . 4.2 The onchange attribute: Handle posture changes The onchange attribute is an event handler IDL attribute for the onchange event handler , whose event handler event type is " change ". 5. Posture types This specification defines the following posture values: Continuous posture: The continuous posture refers to a "flat" position. This is the default case for most devices not allowing different postures. It includes devices with no folds, hinges or similar capabilities. Due to the nature of hardware innovation, it also includes devices with dual, foldable, rollable or curved screens, as long as they are in a posture where the Document is expected to be displayed with a flat layout. Examples of these are: Foldable device in a flat, fully unfolded posture. Foldable device running the browser in a window/section that does not span across the hinge. 2-in-1 device in tablet mode using only 1 screen/side. Devices that do not fold. Note In some cases, devices can run several apps and be in a physical posture other than flat, but as long as the browser does not span through several screens/sections, the corresponding posture is continuous. Folded posture: The folded posture refers to devices that can physically fold. These devices can have one flexible screen or two adjacent screens. This posture forms an angle between the displays/sections that does not exceed a 'flat' position. Examples of these are: Foldable device with a vertical hinge and internal screens being used in a 'book' posture, where the content spans through both sections and forms an angle between ~30° and ~170°. Foldable device with a horizontal hinge and internal screens being used in a 'laptop' posture. Note When a foldable is used in a half-folded state (like a book), implementers might need to take into account the effect of text direction and writing mode on the layout and presentation. For example, right-to-left languages (those that use scripts such as Arabic, Hebrew, Syriac, and others) and many vertical writing modes used by, for example, East Asian languages progress pages in the opposite order to that used by an English book, with the lower numbered page on the right. See Chinese , Japanese , and Korean differences in writing modes for more information. In the API, the posture values are represented by the DevicePostureType enum values. 6. Device Posture Media Queries 6.1 The device-posture media feature The device-posture media feature represents, via a CSS media query [ MEDIAQ ], the posture of the device. All navigables reflect the posture of their top-level traversable . Value: continuous | folded Applies to: visual media types Accepts min/max prefixes: No A user agent MUST reflect the applied posture of the web application via a CSS media query [ MEDIAQ ]. 7. Reading the posture Every instance of Document has an internal slot [[CurrentPosture]] , which should be initialized when the Document is created, otherwise they MUST be initialized the first time they are accessed and before their value is read. The user agent MUST run the device posture change steps with document set to the Document and disallowRecursion set to true to initialize it. For a given Document , the current posture is derived from the current hinge angle and the screen orientation , and potentially other implementation-specific signals. These tables are non-normative. 7.1 Posture values table The values are approximations and might differ per device. For instance, a device might not yield exactly 180° when laying flat, but instead values ranging from 175° to 185°. Device makers SHOULD make sure that the physical device postures map correctly to the postures defined by this specification. Device makers are also allowed to determine the posture using more sensors than just the hinge angle. For example, they can also detect if keyboard is docked on the bottom half of the screen or not. Another example is to detect whether the kickstand is deployed or not. Some devices might also lack one or more of the postures due to physical constraints or device design, in which case the device SHOULD make sure that all combinations of angles and device orientation (which can be locked by [ SCREEN-ORIENTATION ] and host OS), as well as device specific signals, maps into one of the defined postures. 7.1.1 Foldables Posture values for foldable devices Posture Angle value continuous < ~180° folded ~180° 8. Algorithms 8.1 Calculating the device posture information The steps to calculate the device posture information of a Document document are as follows: Let topLevelTraversable be document 's relevant global object 's navigable 's top-level traversable . If topLevelTraversable . [[PostureOverride]] is non-null, return it. Return a DevicePostureType value determined in an implementation-defined way based on the current hinge angle value, current screen orientation , as well as potential implementation-specific signals, according to the posture values table . 8.2 Device Posture change When the user agent determines that the screen(s)' fold angle, orientation or device-specific signals have changed for a top-level traversable , it MUST run the device posture change steps with the top-level traversable 's active document . The device posture change steps for a Document document and an optional boolean disallowRecursion (default false) are as follows: If document 's visibility state is "hidden", then abort these steps. Let posture be the result of invoking calculate the device posture information with document . If posture is equal to document . [[CurrentPosture]] , abort these steps. Queue a global task on the user interaction task source with document 's relevant global object to perform the following steps: Set document . [[CurrentPosture]] to posture . Fire an event named " change " at the DevicePosture object associated with document 's relevant global object 's associated Navigator . If disallowRecursion is true, abort these steps. For each descendantNavigable of document 's descendant navigables : Run the device posture change steps with document set to descendantNavigable 's active document and disallowRecursion set to true. This specification defines the following page visibility change steps given visibility state and document : Run the device posture change steps on document and disallowRecursion set to false to initialize it. Note Developers need to be aware that documents with a "hidden" visibility state will not receive a device posture change event. However, once the document becomes visible again, it will receive the change event. Issue 103 : Avoid using the page visibility change steps hook From https://html.spec.whatwg.org/#update-the-visibility-state It would be better if specification authors sent a pull request to add calls from here into their specifications directly, instead of using the page visibility change steps hook, to ensure well-defined cross-specification call order. As of the time of this writing the following specifications are known to have page visibility change steps , which will be run in an unspecified order: Device Posture API and Web NFC. [DEVICEPOSTURE] [WEBNFC] 9. Security considerations No new security considerations have been reported on this specification. However it is encouraged to look at the potential 10. Privacy considerations listed in this document. 10. Privacy considerations 10.1 Types of privacy threats This section is non-normative. 10.1.1 Identifying users across contexts When this API is used simultaneously in different browsing contexts on the same device it may be possible to correlate the user across those two contexts, creating unanticipated tracking mechanisms. However, because the posture value is typically stable for a long time it could only be used to verify that two users are not the same, but it would not help to identify a given user given the fact that there are multiple types and models of foldable devices. The added entropy is comparable to the pointer API which tells whether the user's primary input is touch-based or not. Such a primary input can change on devices where the keyboard can be removed/added or the tablet mode is activated/deactivated. This theoretical attack is mitigated by 10.2.1 Data minimization , 10.2.2 User attention and 10.2.3 User-mediated action . 10.1.2 Cross-origin iframes Cross-origin iframes have access to the posture through this API and therefore could use this information to identify users similarly to as mentioned in 10.1.1 Identifying users across contexts . The same mitigations apply. 10.1.3 Malicious script injection (for advertising or exploitation) Through iframes, a malicious actor could inject its own code to access the posture information and potentially use it to track users. This theoretical attack is mitigated by 10.2.1 Data minimization as well as the fact that the posture value itself carry little valuable information and stays stable for long period of time. 10.2 Mitigation strategies 10.2.1 Data minimization The API exposes a high-level abstraction referred to as a posture that can be either " continuous " or " folded ". Devices that do not support different postures default to " continuous ". This means at most one bit of entropy is added to the fingerprint. At most, because revealing this one bit will require a significant, explicit physical action by the user to manipulate the physical posture of the device required to trigger a change. While implementations can use a variety of low-level information to determine the most appropriate high-level posture, no low-level details are exposed through this API. Furthermore, there is no one-to-one mapping from any fine-grained low-level sensor reading to a high-level posture state. An implementation can use e.g. a hinge angle sensor, other sensors, information about whether a keyboard is docked, or whether the kickstand is deployed, or any combination of such information, to determine the most approriate posture for the given form factor. This abstraction ensures only a minimum amount of information necessary to implement the intended functionality is exposed adhering to the data minimization principles. 10.2.2 User attention Posture value change events are only fired for each active document whose visibility state is "visible" as explained in device posture change steps , and polling the value while that is not the case, will return a stale value as the value is only updated while the visibility state is "visible" or just changed to "visible". 10.2.3 User-mediated action A user's significant and explicit physical action to modify the device posture is required for a posture change. Significant, because the action must cross the implementation-defined threshold per posture values table , and explicit, because the underlying operating system adapts to posture changes similarly matching user's learned expectations for an outcome of such an action. 11. Accessibility considerations The main focus of the Device Posture API is to improve the user experience. There are three ways in which applications that build on the API can positively impact accessibility. Designing and making applications which do not place content in the fold/hinge area, especially buttons. This area is typically hard to interact with with fingers because the curvature of the fold makes touch less precise or impossible. Designing and making applications which do not put large, contiguous content (such as video or a picture) spanning across the fold/hinge area if the device is folded. This area slightly distorts content and colors. Designing and making applications which use the screen estate better by providing a split UI (a user interface where the content is split up across the screen segments), allowing the application to provide a differentiated and more powerful interface. When using this API it is important to consider the opportunities above with accessibility in mind. Here are few concrete examples: Placement of UI elements: A typical placement logic for dialogs is to center them horizontally and vertically, but in a device folded with a symmetrical fold they may end up in the middle of the fold area making it harder to interact with, for instance clicking on buttons. It might also make it harder to read text due to distortion and light reflection. Fullscreen mode: When resizing an element in fullscreen, a typical logic would expand that element to the width and the height of the Window . If the device is folded, the element will be laid out across the fold, leading to a subpar user experience. An alternative is to display that element either on top or below the fold area. Improving the user experience: With this API it is possible to create a different and adapted user experience when the device is folded, allowing for a better user experience and improved accessibility. For example, when watching a video and the device is folded, the video could be displayed on top of the fold while the comments section could be shown below the fold by default. Another example would be a video conferencing application showing the video feed on top of the fold and the chat below the fold. Content shouldn't be designed for just one posture : The idea of foldable devices is their versatility and the ability for the user to change the posture as they see fit. Similarly to the orientation , it is important to not always choose for the user as they might have other needs but allowing them to choose the UI that fits their needs better. Ideally it is preferred to make the UI configurable. Content announcements for assistive devices: Use ARIA live regions to announce significant layout changes dynamically. For instance, when a fold changes the layout of a webpage, ensure that screen readers announce these changes to users. For example, if a video player is moved to the top of the screen and comments to the bottom, an announcement like "Video player moved to the top screen, comments moved below the fold" can help users navigate better. Assistive technology compatibility: Conduct thorough testing with various assistive technologies to ensure compatibility and proper communication of changes when different postures are reached. 12. Automation The Device Posture API pose a challenge to test authors, as fully exercising interface requires physical hardware devices. To address this challenge this document defines a [ WEBDRIVER2 ] extension commands that allows users to control the reported device posture and simulate a real device. To support the extension commands below and their integration with 8. Algorithms , top-level traversables must have the following internal slots: Internal slot Description [[PostureOverride]] Overrides the current posture provided by the hardware. Possible values: " continuous " " folded " null : Not overriding. The hardware-provided value will be used instead. These values are not exposed directly to script. 12.1 Extension Commands 12.1.1 Set device posture HTTP Method URI Template POST /session/{session id}/deviceposture This extension command changes device posture to a specific DevicePostureType . Properties of the parameters argument used by this algorithm Parameter name Value type Required posture String yes The remote end steps are: Let posture be the result of invoking get a property "posture" from parameters . If posture is not a string , return error with WebDriver error code invalid argument . If posture is neither " continuous " nor " folded ", return error with WebDriver error code invalid argument . Let topLevelTraversable be the current browsing context 's top-level traversable . Set topLevelTraversable . [[PostureOverride]] to posture . Let document be topLevelTraversable 's active document . Invoke device posture change steps with document . Return success with data null . 12.1.2 Clear device posture HTTP Method URI Template DELETE /session/{session id}/deviceposture This extension command removes device posture override and returns device posture control back to hardware. The remote end steps are: Let topLevelTraversable be the current browsing context 's top-level traversable . If topLevelTraversable . [[PostureOverride]] is null , return success with data null . Set topLevelTraversable . [[PostureOverride]] to null . Let document be topLevelTraversable 's active document . Invoke device posture change steps with document . Return success with data null . 13. Examples This section is non-normative. 13.1 Example 1: Posture data This is a simple use case of the posture being printed on the console. Example 1 : React to poster change navigator. devicePosture . addEventListener ( "change" , () => { console . log ( `The current posture is: ${navigator.devicePosture.type} !` ); }) 13.2 Example 2: device-posture The device is being used for a video call web service. It can be folded into the laptop posture to enable a hands-free experience when placed on a surface. The UA detects the posture and the UI is enhanced. Similar examples can be drafted for content to adapt to any posture. See the explainer for other key scenarios. Example 2 : Adapting UI to posture @media ( device-posture : folded) and ( vertical-viewport-segments : 2 ) { body { display : flex; flex-flow : column nowrap; } .videocall-area , .videocall-controls { flex : 1 1 env (viewport-segment-bottom 0 0 ); } } 13.3 Example 3: Feature detection of device-posture media feature As one of the valid device-posture values will always be true, you can use the following snippet to detect whether a user agent supports the media feature: Example 3 : Feature detect the device-posture @media (device-posture) { /*The browser supports device-posture feature*/ } For more information about media features in a boolean context please refer to Evaluating Media Features in a Boolean Context . 14. Conformance As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words MUST and SHOULD in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here. This specification defines conformance criteria for a single product: a user agent that implements the interfaces that it contains. A. IDL Index WebIDL [ SecureContext , Exposed =(Window) ] partial interface Navigator { [ SameObject ] readonly attribute DevicePosture devicePosture ; }; [ SecureContext , Exposed =(Window) ] interface DevicePosture : EventTarget { readonly attribute DevicePostureType type ; attribute EventHandler onchange ; }; enum DevicePostureType { " continuous " , " folded " }; B. Acknowledgments This section is non-normative. We would like to thank Diego González for his major contributions to the specification as the founding editor, and for creating a visual identity to both this specification and the Devices and Sensors Working Group. We would like to offer our sincere thanks to Daniel Appelquist, Jo Balletti, Michael Blix, Paul Grenier and Laura Morinigo for their contributions to this work. C. Summary of substantive changes This section is non-normative. C.1 Changes since the First Public Working Draft (2020/12/17) Remove the rate limiting section per PING review (PR #155) Add two new comments from the accessibility review (PR #149) Update Privacy considerations (PR #145) Add automation support via WebDriver (PR #141) Remove the focus part of the spec (PR #138) Improve the privacy section (PR #132) Add accessibility section (PR #127) device posture change steps: Refer to disallowRecursion by name in calls (PR #128) Modernize algorithms in "Algorithm" section (PR #120) Remove Folded Over from Device Posture (PR #100) Updated folding related concepts (PR #87) Use internal slot (PR #75) Add info about using additional signals (PR #73) Move the entry point of the API to the window.navigator interface (PR #71) Remove fold angle value from the specification (PR #58) Improve the Privacy and Security section (PR #42) Permalink Referenced in: § 4.1 The type attribute: Get current device posture § 7. Reading the posture § 8.2 Device Posture change (2) Permalink Referenced in: § 7. Reading the posture § 12. Automation Permalink exported Referenced in: Not referenced in this document. Permalink exported IDL Referenced in: § 3. Extensions to the Navigator interface § 4. The DevicePosture interface § 8.2 Device Posture change § A. IDL Index (2) Permalink exported Referenced in: § 4. The DevicePosture interface § 5. Posture types § 8.1 Calculating the device posture information § 12.1.1 Set device posture § A. IDL Index Permalink exported Referenced in: § 5. Posture types § 6.1 The device-posture media feature § 10.2.1 Data minimization (2) § 12. Automation § 12.1.1 Set device posture Permalink exported Referenced in: § 5. Posture types § 6.1 The device-posture media feature § 10.2.1 Data minimization § 12. Automation § 12.1.1 Set device posture Permalink exported IDL Referenced in: § 4. The DevicePosture interface § A. IDL Index Permalink exported IDL Referenced in: § 4. The DevicePosture interface § 4.2 The onchange attribute: Handle posture changes (2) § A. IDL Index Permalink Referenced in: § 8.2 Device Posture change Permalink exported Referenced in: § 5. Posture types § 6.1 The device-posture media feature (2) (3) § 10.2.1 Data minimization § 11. Accessibility considerations § 13.1 Example 1: Posture data § 13.2 Example 2: device-posture Permalink Referenced in: § 6.1 The device-posture media feature Permalink Referenced in: § 8.1 Calculating the device posture information § 10.2.3 User-mediated action Permalink Referenced in: § 8.2 Device Posture change Permalink Referenced in: § 7. Reading the posture § 8.2 Device Posture change (2) (3) § 10.2.2 User attention § 12.1.1 Set device posture § 12.1.2 Clear device posture Permalink Referenced in: § 7. Reading the posture § 8.2 Device Posture change Permalink Referenced in: § 7. Reading the posture § 8.2 Device Posture change (2) Permalink Referenced in: § 8.1 Calculating the device posture information § 12.1.1 Set device posture § 12.1.2 Clear device posture (2) Permalink Referenced in: § 7. Reading the posture D. References D.1 Normative references [dom] DOM Standard . Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/ [HTML] HTML Standard . Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/ [infra] Infra Standard . Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/ [MEDIAQ] Media Queries Level 4 . Tab Atkins Jr.; Florian Rivoal. W3C. 19 February 2026. CRD. URL: https://www.w3.org/TR/mediaqueries-4/ [RFC2119] Key words for use in RFCs to Indicate Requirement Levels . S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119 [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words . B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174 [SCREEN-ORIENTATION] Screen Orientation . Marcos Caceres. W3C. 21 October 2025. W3C Working Draft. URL: https://www.w3.org/TR/screen-orientation/ [WEBDRIVER2] WebDriver . Simon Stewart; David Burns. W3C. 11 May 2026. W3C Working Draft. URL: https://www.w3.org/TR/webdriver2/ [webidl] Web IDL Standard . Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/ D.2 Informative references [clreq] Requirements for Chinese Text Layout - 中文排版需求 . Fuqiao Xue; Richard Ishida. W3C. 3 May 2026. DNOTE. URL: https://www.w3.org/TR/clreq/ [jlreq] Requirements for Japanese Text Layout 日本語組版処理の要件(日本語版) . Hiroyuki Chiba; Junzaburo Edamoto; Richard Ishida; Seiichi Kato; Tatsuo KOBAYASHI; Toshi Kobayashi; Nathaniel McCully; Felix Sasaki; Atsushi Shimono; Hajime Shiozawa; Fuqiao Xue et al. W3C. 11 August 2020. W3C Working Group Note. URL: https://www.w3.org/TR/jlreq/ [klreq] Requirements for Hangul Text Layout and Typography - 한국어 텍스트 레이아웃 및 타이포그래피를 위한 요구사항 . Richard Ishida. W3C. 21 March 2026. DNOTE. URL: https://www.w3.org/TR/klreq/ ↑