Browser support - Playground

Official support

The playground runs in current browsers. The official statement is the live table at browsers.page, which lists the current and the previous release of Chrome, Edge, Firefox, Safari and Samsung Internet. The page also shows your own browser, and marks it in green, or in red when your version is older than the oldest one listed. Look there for version numbers, because they change with every release. See browsers.page.

The editor has no version check and no user-agent block. Every browser loads the same app, and features are shown, hidden or registered by feature detection, and by whether the playground is embedded.

Requirements

Service workers

The output document registers a service worker, and the playground waits for it: the output announces that it is ready only after the registration succeeds. A browser without service workers cannot run the playground. Firefox before version 139 had no service workers in private windows. Whether the playground works in a private window of a current Firefox is untested.

Modern JavaScript

The editor uses these built-ins without fallbacks. The table shows the first version of each browser that has them.

Built-in	Used for	Chrome and Edge	Firefox	Safari and iOS	Samsung Internet
`Set.prototype.difference`	the state of the URL, on every load	122	127	17	26
`Promise.withResolvers`	waits for the output	119	121	17.4	25
`AbortSignal.any`, `AbortSignal.timeout`	events, Remote Output	116	124	17.4	24
`Map.groupBy`	errors of the Output settings	117	119	17.4	24
`Array.fromAsync`	emptying a shared folder	121	115	16.4	25
Compression Streams, `gzip`	compressed links	80	113	16.4	13
`Uint8Array.fromBase64`, `toBase64`	compressed `v=2` links only	140	133	18.2	30

From the first six rows, the core playground needs at least Chrome and Edge 122, Firefox 127, Safari 17.4 and Samsung Internet 26. This floor is derived from the browser compatibility data. It is not a tested policy.

Compressed long links

A state of 8192 characters or more is written as a compressed v=2 link, which needs Uint8Array.prototype.toBase64 and fromBase64: Chrome and Edge 140, Firefox 133, Safari 18.2 and Samsung Internet 30. In a browser without them, opening such a link, opening the source of a large deployment, or saving a playground whose state reaches 8192 characters fails, and a notice reads Could not read or save the playground hash. Samsung Internet 29, which the official table listed in October 2026, is below that line. See Linking to and embedding the playground.

Features with fallbacks

State-preserving moves. Sync moves DOM nodes with moveBefore() where it exists: Chrome and Edge 133, Firefox 144, Samsung Internet 29, and not Safari. Elsewhere it uses insertBefore(), which does not keep the state of a moved iframe.
Parsed HTML. Sync uses setHTMLUnsafe() where it exists: Chrome and Edge 124, Firefox 123 and Safari 26 in full. In Safari 17.4 to 25 it is partial: the constructors and connectedCallback of custom elements inside declarative shadow roots in the parsed HTML are not called.
The editor's own style. It uses CSS nesting, :has(), light-dark(), oklch, @container and @scope, with @scope in Chrome 118, Firefox 146 and Safari 26.4. In older engines these change how the editor looks, not what it does. This was not checked visually.
Blocked storage. If localStorage throws, the playground works without remembering window positions, the capture target, Auto-Share and similar settings.

In Safari, and in every browser on iPhone and iPad, the output document gets an Element.prototype.moveBefore that only calls insertBefore. Code that tests for moveBefore sees it in the playground, and does not on a deployed page. See Playground and edge differences.

What needs Chrome or Edge

Agent Folder Share and what comes with it

The whole Agent block of the playground runs only where FileSystemObserver exists and the playground is not embedded. That is desktop Chrome and Edge 133 and later; the compatibility data also lists Opera 118. It does not exist in Chrome or Samsung Internet on Android, in Firefox, or in Safari and iOS. Other Chromium browsers on a computer pass the gate only if they expose FileSystemObserver; that is untested, and some ship the File System Access API disabled.

The block holds:

Agent 📂 Share™: Share, Share + Output, Unshare, Auto-Share, Share ← Folder and Unlink Root;
File Sync, and the file evals io.eval.js and o.eval.js;
the folder files 📄.sel, 📜.json and 📸.png;
Pins, Ctrl+P / ⌘+P, and the o.pins API;
the lookup of authored source, o.input and sync.input;
pasting and dropping images into the input as data: URLs;
the Agent Folder explorer.

Without the gate, the Agent section of the File menu is hidden and the palette has no Agent commands. A framed playground never gets Agent Folder Share, not even in Chrome. In a frame, Open ▸ Playground ▸ Tab opens the same state in a top-level tab, where it works.

To tell your visitors, test for the same API:

html

<p id=agentNote>Agent Share needs Chrome or Edge on a computer.</p>
<script>agentNote.hidden = 'FileSystemObserver' in globalThis</script>

The note disappears in a browser that has FileSystemObserver. The playground's own gate also needs a top-level playground, so this check only reports what the browser supports.

The address bar during a share

In Chromium browsers, the playground stops writing the address bar while a folder is shared, because Chromium records replaced URLs in history. The state is saved for a reload in the session storage, and a reload of the same tab reconnects the share. Other browsers never pause. See Agent 📂 Share™ and Linking to and embedding the playground.

Screen capture

getDisplayMedia(). The Capture section needs it: Chrome and Edge on a computer, Firefox on a computer from 66 and Safari from 13. It does not exist in Chrome or Firefox on Android, in Samsung Internet, or on iPhone and iPad.
Targets. The chooser, Window, Playground, Input or Output, appears only where CropTarget exists, in Chrome and Edge on a computer from 104. Input and Output restrict the capture to a panel with RestrictionTarget, from 132. In Firefox and Safari there is no chooser, and a capture of the output is not restricted to the panel: it captures whatever surface you pick.
Picture-in-picture. The preview needs requestPictureInPicture(): Chrome from 69, Edge from 79, Firefox from 153, Safari from 13.1, and Chrome on Android from 105. Safari gets a docking workaround.
Embedded. A framed playground hides the Capture menu, keeps the commands in the palette, and can capture only if the embedding page delegates display-capture.

See Screen capture.

Native preference overrides

The output settings for reduced motion, contrast, reduced transparency and reduced data, orm, opc, ort and ord, call navigator.preferences in the output document. That API exists in Chrome and Edge 120 and later only behind Experimental Web Platform features, chrome://flags/#enable-experimental-web-platform-features, and not in Firefox or Safari. A setting is available only if every connected output supports it, so connecting a Remote Output device that does not can disable it. Otherwise applying a value fails with This browser does not support this preference override.

The Output settings dialog hides these rows when the browser lacks the API. Check Show unsupported to see them, disabled, with a status line. The other output settings, odir, olang, ofs, oas, ovp, oz and ovfit, work in every current engine, and the color scheme has a Safari caveat. See Output settings.

Safari, iPhone and iPad

Every browser on iPhone and iPad is built on WebKit, so what this section says about Safari holds for Chrome, Edge and Firefox there too.

The output origin. The output always runs on out.rtcode.net, also in a top-level playground, because Safari has no window.originAgentCluster. The two output origins have separate service workers, playground KV data and session state. Popups and tabs always use out.rtcode.net too, so in Safari every output shares that origin.
No Enable output button. If the output cannot register its service worker, Safari gets neither the button of the Storage Access API nor a message. See Troubleshooting.
The color scheme. The Color Scheme row of the split popover opens a WebKit bug report instead of toggling it. A right-click on the row, Ctrl+Alt+C / ⌘+⌥+C, ocs and the Output settings dialog set the scheme as usual. In Safari versions that predate the upstream fixes, CSS of the output that uses prefers-color-scheme may not follow ocs. Whether Safari 27 does is untested.
State-preserving moves. Safari has no native moveBefore(), so sync uses insertBefore(), and the output gets the playground-only moveBefore that is described above.
Parsed HTML. setHTMLUnsafe() is complete from Safari 26.
Windows. The playground waits 300 ms before it opens an output popup or tab, and a Versions window.

Firefox

Firefox support for the playground itself is untested: no test report drives its editor. The required APIs are there from Firefox 127, and from 133 for compressed links. The tests that cover Firefox are the parser-safety tests of the sync engine, and the UI of another app.

Remote Output Experimental. Firefox can be either end of a session.
Request bodies. Firefox has Request.body only as a preview feature, and the playground's worker bridge relies on it for the bodies of requests that the output sends to a playground worker. Such POST and PUT bodies may not arrive. Test that code in Chrome or Edge.
Embedding. Whether an embedded playground works in Firefox is untested.

Phones and tablets

Key hints, hover-opening menus and hover tooltips follow the pointer. They are hidden or disabled where the primary pointer is not fine, and on touch-only devices, where you tap. The Popup item of the Open menu is hidden on touch-only devices, and Tab and Remote stay. Dragging the toolbar ignores touch, which scrolls it as usual.

On phones and tablets these features are not available: Agent Folder Share and what comes with it, screen capture, Fullscreen on iPhone, while iPad has it with an overlay button that cannot be hidden and a swipe down that exits, and native preference overrides, except in Chrome on Android behind the flag, which is untested. Output tabs, Remote Output, the Output settings dialog and editing work.

Note: The tests on phones are few. A person saw live edits on an iPhone, and layout screenshots of iOS 27 show the toolbar, also with the software keyboard open. Native touch gestures, orientation changes and the keyboard were not verified, and nothing was tested on Android.

Windows and embeds

Popups and tabs

New Output Window opens https://out.rtcode.net in a popup or a tab, and Versions and Compare open windows too. Keyboard shortcuts count as user activation. A browser can still block a window, and a blocked window shows no message from Versions. Allow pop-ups for rtcode.io and run the command again. See Troubleshooting and Output windows.

Embedding

Any site can embed the playground. In a frame, the output runs on out.rtcode.net, and a few features depend on the embedding page: the Fullscreen commands exist only if the frame allows fullscreen, capture needs display-capture, and storage in the output can need a click on Enable output, in browsers that have the Storage Access API and are not Safari. Embedding in Firefox is untested. See Linking to and embedding the playground.

Installing as an app

The playground itself is not installable. It has no web app manifest, and /manifest.json returns 404. It sets apple-mobile-web-app-capable and a title, which name an iOS home-screen bookmark; how iOS and Safari treat that for the playground is untested.

A deployment can be an installable app if it serves a manifest, from a worker or from an exported file. Set the content type of an exported manifest yourself, for example with o:type=application/manifest+json (see o:type), because the deploy compiler has no entry for .webmanifest. In Chrome a manifest and its icons were parsed. On iOS 27, use Share, Add to Home Screen, and Open as Web App. Firefox and Android were not tested.

Web Push and app badges Experimental

Web Push on push.rt.ht and wp.rt.ht is experimental and depends on the browser: PushManager exists in Chrome 42, Edge 17, Firefox 44 and Safari 16, notifications in Safari need macOS Ventura, and on iOS from 16.4 only in web apps that you saved to the Home Screen. The declarative form, window.pushManager, is in Safari and iOS 18.4. setAppBadge() exists in Chrome and Edge 81 on Windows and macOS, in Safari 17 for installed web apps, and on iOS 16.4 for Home Screen apps; Chrome on Android and Samsung Internet only clear a badge, and Firefox has none. See Web Push.

Deployments and workers

A signed-in deployment inside a frame of another site relies on partitioned cookies: Chrome and Edge 114, Firefox 141, Safari 26.2 and Samsung Internet 23. A Safari without them treats the cookies as third-party cookies, which it blocks by default, so a signed-in embed there probably needs the Storage Access API. The popup forms of sign-in need a popup that the browser allows, and an opener of the same origin. This was not tested per browser. See Adding sign-in.

A worker of the playground runs in the output's service worker, so it has the Web APIs of your browser. A deployed worker runs on Cloudflare's runtime, with its APIs. A feature that a browser lacks can be missing in the playground and present at the edge. Post-quantum Web Crypto is an example: it is in RTEdge.net workers, and in the playground it depends on the browser. Detect support in code instead of reading version numbers. See Post-quantum cryptography and Playground and edge differences.

Availability matrix

The columns are the current releases. Android means Chrome, Edge and Samsung Internet on Android, and iPhone and iPad means every browser there, all of which are WebKit. Tested cites the evidence below, Untested means the code path exists and nobody has tested it, and n/a means that the feature does not apply.

Feature	Chrome and Edge, desktop	Firefox, desktop	Safari, macOS	Android	Firefox, Android	iPhone and iPad
Core playground: edit, live output, sync, workers, deploy	Tested	Untested	Tested	Untested	Untested	Seen on iOS
Compressed long links, `v=2`	140+	133+	18.2+	Chrome 140+, Samsung 30+	133+	18.2+
Agent Folder Share, File Sync, file evals, Pins, `o.input`, `📸.png`, image paste, Explore	133+, top level	No	No	No	No	No
Address-bar pause and reload recovery during a share	Yes	n/a	n/a	n/a	n/a	n/a
Screen capture: Window, Image, Video	Yes	Yes	Yes	No	No	No
Capture target Playground, Input or Output	104+, 132+	Unrestricted	Unrestricted	No	No	No
Picture-in-picture for a capture	Yes	153+	Docking workaround	n/a	n/a	n/a
Native preference overrides	Flag	No	No	Chrome, flag, untested	No	No
Output color scheme, `ocs`	Yes	Untested	Toggle row opens a bug	Untested	Untested	As Safari
`odir`, `olang`, `ofs`, `oas`, `ovp`, `oz`, `ovfit`	Yes	Yes	Yes	Yes	Yes	Yes
Fullscreen commands	Yes	Yes	Yes	Yes	Yes	iPad only
Output in a tab	Yes	Yes	Yes, +300 ms	Yes	Yes	Yes, +300 ms
Output in a popup, menu item	Yes	Yes	Yes	Hidden on touch	Hidden on touch	Hidden on touch
Remote Output Experimental	Experimental	Experimental	Experimental	Experimental	Experimental	Experimental
Remote Output Share button	Chrome 128+, Edge 93+	Flag only	Yes	Yes	Yes	Yes
Playground in a frame of another site	Reduced menus	Untested	Reduced; out.rtcode.net	Reduced	Reduced	Reduced
Enable output button for a framed output	Yes	Yes	No button	Yes	Yes	No button
Key hints, hover menus and tooltips	Fine pointer	Fine pointer	Fine pointer	Hidden on touch	Hidden on touch	Unless fine pointer
Install the playground as an app	No manifest	No manifest	No manifest	No manifest	No manifest	Bookmark title
Install a deployment that serves a manifest	Yes	Untested	Yes	Untested	Untested	Yes
Web Push in `wp.rt.ht` and `push.rt.ht` Experimental	Experimental	Experimental	Experimental	Experimental	Experimental	Home Screen app
App badges	Not on Linux	No	Installed app	Clear only	No	Home Screen app
Signed-in deployment in a cross-site frame	114+	141+	26.2+	Yes	Yes	26.2+
State-preserving moves in sync, `moveBefore`	133+	144+	Fallback and shim	Chrome 133+, Samsung 29+	Yes	Fallback and shim

What has been tested

Chrome. The core playground in Chrome 152 to 154, a layout check of 35 of 35 in Chrome 153, and phone-sized viewports in desktop Chrome.
Safari on a Mac. Safari 26.6.2: 40 of 40 readiness and rendering checks, and 4 of 4 checks of sync from the output, on 13 September 2026. The 13 live checks of that day first passed 10, and the three failures, a race in repeated readiness messages, were fixed the same day.
Safari on iPhone. A person watched live edits on iOS 26.6.2, and screenshots of iOS 27 and Safari 27 show the layout in all four layouts, also with the keyboard open. Safari WebDriver could not start a session.
Sync engine. The parser-safety corpus of 1,918 cases is clean on Chromium, Firefox, Safari 26.5.2 and Safari Technology Preview 247. Chrome remains the oracle of the engine.
Firefox and Android. No test drives the playground editor in Firefox, and nothing was tested on Android.