YT Zero Enhance — bringing the embedded player closer to the native YT Zero experience

[Pelski]

Hey everyone!

I’ve been working on YT Zero Enhance, a browser extension built specifically for YT Zero.

Repository: Pelski/ytzero-enhance

Why did I build it?

YT Zero can use both its local player and an externally embedded player.

The local player is fully controlled by the application, but an embedded cross-origin iframe is intentionally isolated by the browser. Regular application code cannot reach inside it to:

• customize its interface;
• reliably control playback behavior;
• provide consistent keyboard shortcuts;
• manage captions and language selection;
• capture the visible video frame;
• synchronize fullscreen, theatre mode and player state with the parent application.

These restrictions cannot be solved properly from inside a regular web application. They are enforced by browser cross-origin boundaries.

A browser extension is the appropriate way to bridge that boundary. With explicit permission from the user, YT Zero Enhance can run inside the embedded player and exchange a small, strictly validated set of events with the connected YT Zero instance.

What does YT Zero Enhance add?

A YT Zero-style control bar

The extension can replace the standard embedded-player interface with controls designed to match YT Zero:

• play and pause
• seeking and buffering progress
• volume and mute
• caption language selection
• Picture-in-Picture mode
• fullscreen
• YT Zero theatre mode
• chapter markers
• SponsorBlock segments
• automatic hiding of the controls and cursor

Double-clicking the player surface toggles fullscreen! 🎉

Active profile synchronization

The extension reads the safe configuration exposed by the currently active YT Zero profile. The embedded player can therefore respect:

• default playback speed
• configured seek interval
• preferred quality
• default caption language and appearance
• screenshot format and filename settings
• SponsorBlock categories

Changing the active profile can also update the behavior of the embedded player.

Frame capture

The extension can capture the currently visible video area, crop it correctly and save it as PNG, JPEG or WebP. The local player can still provide better quality because it has direct access to the original video dimensions.

Link redirection

Supported watch, short-form, live and shortened video links can be redirected to the default YT Zero instance. Timestamps are preserved, so links pointing to a specific moment continue to open at that position.

Redirecting links is optional and can be disabled at any time.

Privacy

The extension has no analytics, advertising or external backend.

It does not send browsing history, credentials, player activity, configuration or captured images to me. Preferences and connected instances remain in browser-managed extension storage.

Availability

Builds are available for Chromium-based browsers, Firefox and Safari.

I have submitted the extension to browser extension stores and I am currently waiting for the listings to be reviewed and approved. I will add the official installation links as soon as they become available.

Until then, the extension can be built and installed manually by following the instructions in the README.

Feedback is very welcome, especially for different browsers, reverse-proxy configurations and embedded-player variants. If you encounter problems with controls, captions, fullscreen, profile synchronization or frame capture, please report them in the extension repository.

I hope you like it!

--
Happy watching!
Pelski

Note

If you want to use only redirect feature, I recommend the community browser add-on pekempy/YTZero-Redirect

[farfromexact]

The extension is a sensible boundary for the embedded player: a normal parent application cannot reliably control a cross-origin iframe, so trying to solve this entirely inside the web app would fight the browser security model.

The part I would make especially strict is the bridge between the extension and YT Zero. I would recommend:

1. Use the narrowest host permissions possible.
2. Validate both event source and origin on every postMessage.
3. Establish a per-tab nonce during the handshake.
4. Accept a small versioned message schema, not arbitrary commands.
5. Reject unknown message types and oversized payloads.
6. Keep profile synchronization to an allowlisted set of values.

The parent should also degrade gracefully when the extension is absent, disconnected, or updated. Local-player controls should remain available, and the embedded player should not look half-initialized while waiting for the bridge.

For frame capture, make the permission and quality tradeoff explicit: the local player can access original dimensions, while an embedded capture is limited by what the browser exposes to the extension. Fullscreen, theatre mode, captions, and keyboard shortcuts should each have a clear ownership rule so the parent and iframe cannot fight over focus.

This looks like a useful companion project. A protocol document with message examples, versioning, and the trust boundary would make it easier for the main app and third-party extensions to evolve without silently breaking each other.

[Pelski]

Thanks - that matches the project’s approach. Host access is requested only for the explicitly paired origin, and the bridge uses same-document CustomEvents plus internal extension messaging, not postMessage, so source/origin checks and a DOM-visible nonce would not add meaningful security. Messages and profile values already use versioned, allowlisted schemas; unknown commands are rejected.

I’ll add pre-parse payload size limits and improve fallback after extension updates. Native/local controls remain available without the extension, capture quality and permissions are documented, and ownership is split clearly between parent layout/theatre mode and iframe media controls. A versioned protocol document with examples and trust boundaries already exists. I’ll make it easier to discover from the README 🙂