What Is Picture-in-Picture, and Why Is It Video-Only on Mac?

You’ve probably met “picture-in-picture” in three places: the PIP button on an old TV remote, the floating-video icon on a streaming site, and that little rectangle in a Mac video player. They’re the same idea with three different implementations.

The definition

Picture-in-Picture means one picture overlaid on top of another — a small window playing a second feed above the main one.

It started on televisions in the 1980s: main screen for the match, corner window for the other one. Back then it was physical — two tuners inside the TV, composited into one image.

On a computer, the concept survived but the implementation changed entirely. Nothing is composited in hardware; software renders one video stream as a separate floating layer.

How macOS does it

Since Sierra (2016), macOS has had system-level PiP, implemented through AVKit. A player calls the system API, and the system lifts the video out into an independent floating window above all apps.

The crucial detail: the player triggers it. Not the user, not the system.

Which means:

• Only players that implement the PiP API can use it (Safari, Chrome, QuickTime, IINA…)
• The content must be video media, because that’s the only thing the system recognises here
• Only one at a time — the system defines PiP as “the floating view of the current video”, singular

Why you can’t float anything else

This is the question everyone asks: why can’t a chat window, a terminal, or a web page use PiP?

Because there is no system path for “turn any window into PiP”. The mechanism requires a player handing over a video stream. A chat window has no video stream to hand over, so the system has nothing to render.

Floating arbitrary windows needs a different mechanism: window capture (ScreenCaptureKit), which reads frames from a window and renders them yourself. That only became available with macOS 13, and it requires the user to grant Screen Recording permission.

That’s the fundamental difference between native PiP and a window-level tool:

	Native PiP	PipNow
Mechanism	player hands over a video stream	captures the whole window
Target	video media	any window
Requirement	player support	Screen Recording permission
Count	one	unlimited

Three common misconceptions

“PiP is just a small window.” Not quite. Small is the shape; the defining property is that the content stays live. Shrinking a window isn’t PiP. Mirroring its contents is.

“PiP is expensive.” Depends on the content. A static page (code, a document) costs almost nothing. Video keeps decoding, roughly the same as playing it normally.

“PiP records my screen.” Native PiP doesn’t — it only renders video. Tools that use window capture do need Screen Recording, but that’s a live in-memory mirror, not a recording. Worth a full explanation: why PiP apps need screen recording.

One sentence

PiP = shrinking one picture and floating it above another. TVs did it in hardware, browsers do it through the player API, and a general solution on the Mac does it through window capture. The first two handle video only; the third handles anything.

If your need is “watch video while doing something else”, the built-in feature is enough. If it’s “keep an eye on a chat, a terminal, or a chart”, you need the window-level approach — here’s how that works.