You are explaining something and you need to point at a specific thing on your screen. The usual move is to take a screenshot, open it in some editor, draw a red circle on it, and send the picture. That works right up until the screen changes. The spreadsheet scrolls, the dashboard refreshes, the app advances to the next step — and your annotated screenshot is now a picture of a moment that has already passed. What you wanted was to draw on the screen, not on a photograph of it.
The full-screen board app can do exactly that. Open the board, choose Share my screen, pick what you want to share in the browser's own dialog, and your screen appears behind the canvas. From there you draw over it with the same pen, arrows, shapes, sticky notes and text the board has always had — except what is underneath is live and keeps updating while you annotate. This guide covers how to start a share, what the board is really doing when it puts a screen behind your drawing, what the recording contains, and the one thing to be clear about before you rely on any of it: a shared screen is never saved.
Why a Screenshot Stops Being Useful the Moment Something Moves
A screenshot is a good annotation surface for something that is finished. A mockup, a printed report, a bug you have already reproduced and frozen — capture it once, mark it up, done. The trouble starts whenever the subject is still moving. A live dashboard refreshes while you are drawing the arrow. A form validates as you type into it. A build log scrolls. A map re-renders when you zoom. In every one of those cases, the instant you capture a still you have stopped talking about the thing and started talking about a memory of it.
The second problem is the detour. Annotating a screenshot means capture, switch app, paste, draw, export, switch back, share — six steps, three of which involve a file you did not really want to create. Half the time you are mid-sentence in a call while doing it, and everyone is watching you hunt for the crop tool. Drawing straight over the live screen removes both problems at once: nothing is captured, nothing is exported, and what you circle is the thing itself rather than a copy of it that started aging the second it was taken.
Putting Your Screen Behind the Board
Open the full-screen board app. In the toolbar there is a small group of background controls: one to use an image file as the background, one to share your screen, and — once a background is attached — one to remove it again. Click Share my screen and your browser takes over: it opens its own picker, the same one you see when you share on a video call, and asks what you want to share. That dialog is the browser's, not the page's. You choose whether it is a single browser tab, one application window, or an entire display, and the page only ever receives what you selected there. If you change your mind, dismiss the picker and nothing happens at all — the board is left exactly as it was.
Once you confirm, the shared surface appears behind the canvas, scaled to fit, and you draw on top of it. Everything else about the board works normally: the pen and highlighter, shapes with dashed or dotted lines, arrows with a head at either end, text, sticky notes, undo and redo, alignment guides. If instead you want a static picture to mark up — a screenshot you already took, a photo, a floor plan, a diagram exported from somewhere else — use Image as background and pick the file. It behaves the same way, minus the movement — and, unlike a shared screen, it stays with the board once it is there. Whenever you want the surface back to plain white, Remove background detaches it and, if a screen was being shared, stops the share.
What "Behind the Board" Actually Means
It is worth being precise about the mechanism, because the two kinds of background are built differently and that is what explains the behaviour you will notice later. The board is a single HTML canvas redrawn from scratch every frame, and everything you draw lives in an ordered list of objects called the scene. An image background joins that list: the picture is sized to the view you are looking at and inserted as a locked image object at the very back of the stacking order — an ordinary member of the scene that happens to sit behind everything and refuse to be dragged. A live screen cannot join it, because a stream is not a value you can put in a list. It is painted separately instead, ahead of the scene: the stream is drawn first, then the optional dot grid, then every shape and stroke in order. Either way the pixels end up in the same canvas; your drawing is never floating in a separate transparent layer on top of a video element.
For a live share, the source is a <video> element carrying the stream the browser handed over. A video element does not tell the canvas when it has a new frame, so the board runs a repaint loop while a share is active, redrawing on each animation frame so the background stays current. That loop exists only while a screen is actually shared; stop the share and it stops with it. An image background needs none of this — it is redrawn from the scene like any other object, and very large pictures are downscaled to a sane maximum before they are stored, because a background is only ever shown scaled to the view and a 12-megapixel photo would cost memory, and save-file size, for no visible gain.
Annotations That Stay Glued to What They Point At
The detail that makes this usable rather than merely impressive is that the background is placed in the board's world coordinates, not pinned to your screen. The board is an infinite canvas with a camera over it; panning and zooming move the camera, not the drawing. When a background is attached, its rectangle is worked out once in that same world space and then carried by the same camera transform as everything else.
The practical consequence: if you zoom into a corner of a shared dashboard to circle one number, the circle and the number zoom together and stay aligned. Pan sideways and both slide off in step. Had the background instead been re-fitted to the viewport on every frame, the camera would have cancelled itself out and the image would have been screen-locked — your arrow would drift off the thing it was pointing at the first time you moved. Because the background is anchored in the world, annotations stay glued to what they point at, which is the entire reason to annotate over something rather than beside it.
Nothing Is Uploaded, and the Browser Decides What Is Shared
Screen sharing sounds alarming until you look at where the pixels actually go. The board obtains a stream through the browser's Screen Capture API, and that stream is consumed on your own machine: it is drawn onto a canvas in the same tab and nowhere else. There is no server in the path. No frame is uploaded, no session is created, no account exists to attach anything to. Close the tab and the stream ends with it.
The browser also holds the controls, by design. The W3C Screen Capture specification requires that a capture only begins in response to a user gesture and after the user has explicitly chosen a display surface — which is why the picker is drawn by the browser rather than by the page, and why a site cannot pre-select what you share or start a capture on its own. While a share is running, your browser shows its own sharing indicator, and you can end the share from there at any moment without touching the page. If you do, the board notices immediately: the background clears, the repaint loop stops, and a screen-reader announcement confirms the background was removed. This is the same privacy model as the rest of the board, which never sends your strokes anywhere either — see the case for a whiteboard with no sign-up for how that plays out across the whole tool.
What Is Saved: the Image Stays, the Screen Does Not
Say this one plainly, because assuming otherwise will cost you work: a live screen is a stream, not data, and it is never saved. The board's saved file — the JSON scene you export, and the local autosave that offers to restore your last board — contains the objects you drew and nothing that was merely streamed through. There is no frame of your screen in it. The exports say the same thing: PNG, SVG and PDF are all generated from the scene, so a shared screen appears in none of them. Reopen that board tomorrow and your drawing comes back exactly as you left it, floating over a blank canvas, and if you want the screen behind it again you share again.
A background image is the opposite case, and the difference is worth internalising, because it used to work the other way. A picture you choose as the background is not a viewing effect painted under the drawing — it is placed in the scene, as a real image object, locked and pushed to the very back. That single fact carries all the consequences you would hope for: it is written into the JSON you export, kept by the local autosave, restored where it was when you reopen the board, and drawn into the PNG, SVG and PDF exports underneath everything you annotated on top of it. Export an SVG and the picture is embedded in the file; export a PNG and it is baked into the pixels. Nothing extra is asked of you — mark up a screenshot, close the tab, come back tomorrow, and the screenshot and your arrows are both still there.
Which leaves a fair question: if a background image is saved anyway, when should you use the ordinary Add image tool instead? The answer is no longer about persistence — both persist — but about role. Image as background is for a picture you are drawing on. It arrives sized to fit inside the view you are looking at — scaled down until the whole picture is visible, letterboxed rather than cropped — it sits behind every shape, and it is locked, so a stray drag never pulls it out from under your annotations, and choosing a second background replaces it rather than piling one behind the other. Add image is for a picture that is one element of the artwork among several. It arrives unlocked at its own size, and you move it, resize it, rotate it and layer it above or below other shapes, as many as you like. The rule of thumb: one thing you annotate over, use the background; several things you arrange, use Add image. And use Share my screen when the subject is still moving and a still would already be out of date by the time you finished drawing on it. Our guide to exporting a whiteboard to PNG, SVG and PDF covers what each of those files actually contains.
Recording: Vectors by Default, the Screen Only if You Ask
The board can record a narrated session, and the way it does that interacts with backgrounds in a way worth understanding. By default the recorder does not capture pixels at all — it stores your microphone audio alongside a series of scene snapshots. Replay is therefore a re-performance: the board replays the drawing from the snapshots in step with the audio, which is why you can scrub the timeline and why the result stays crisp at any size. It is also why, by default, a session recorded over a shared screen exports as your strokes on their own: there were never any screen pixels in the recording to begin with.
That is fine for a diagram you drew from scratch, and useless for a walkthrough of a live dashboard. So when a screen is actually being shared, an extra checkbox appears next to the record button: include the screen in the recording. Tick it before you record and the board additionally records the composited canvas itself — screen and strokes together, exactly as they looked — mixed with the same microphone track. Export then hands you that file instead of the replay. The difference matters most after the fact: the replay export can only ever show whatever the background happens to be at the moment you export, so if the share has already ended you would get a video of your annotations over nothing. The opt-in recording is a real capture of what was on the canvas at record time, so it survives the share ending, which is usually the exact video you wanted.
Two honest caveats. The checkbox only appears when a live screen is behind the canvas and your browser supports the video export, which uses the MediaStream Recording API to produce a WebM file — that means Chrome, Edge or Firefox, not Safari. And if you end the share midway through recording, the capture is stopped and finalised right there rather than quietly continuing over an empty canvas; you get a shorter but valid video and a message telling you why. For everything else about recording — narration technique, scrubbing the replay, saving a project file — the companion guide on recording a narrated whiteboard walkthrough goes deeper.
Clean Mode: Hide Every Control, Hold Alt to Bring It Back
Once there is a screen behind the canvas, the board's own toolbar is suddenly in the way. It is floating over the very thing you are trying to show, and if you are presenting or recording, your audience sees it too. Clean mode removes it: one toggle hides the toolbar, the corner panels, the style palette, the minimap, the hint button and even the links out of the board app, leaving nothing but your screen and your drawing.
Hidden chrome is genuinely hidden, not merely invisible — the hidden controls are marked inert and hidden from assistive technology, so you cannot Tab onto an invisible button by accident and a screen reader will not read out a toolbar nobody can see. To get the controls back for a second, hold Alt (Option on a Mac): the chrome reappears while the key is down and vanishes when you release it. Alt is used because the board's other obvious modifiers are already taken — Shift adds to a selection and constrains proportions, and the space bar pans the canvas — so borrowing either of those would have broken drawing. If you are on a touchscreen with no Alt key at all, a small pill stays at the top centre of the screen while clean mode is on — exactly where the toolbar reappears — with a finger-sized tap area around it; tap it to bring the controls back and tap again to send them away. The reveal never latches: alt-tabbing to another window, switching tabs or opening a context menu all put the chrome back down, so you cannot leave the room looking at a toolbar you thought you had hidden. If distraction-free work is the whole point for you, the focus case for a bare canvas makes the argument in full.
Where This Works, and Where It Does Not
Screen sharing depends on the Screen Capture API, and that API is a desktop feature. Safari on iPhone and iPad does not implement it at all, and neither do the Android builds of Chrome or Firefox. Rather than offer a button that fails, the board simply does not show Share my screen when the API is missing — so on a phone or tablet you will see the image background option and not the screen one. The image background still works everywhere, which covers the common mobile case of marking up a screenshot you just took — and because that one is saved with the board, the markup survives closing the tab.
On the desktop, the feature is available in the full-screen board app rather than the in-page whiteboard, because that is where it makes sense: a screen annotation surface should be the whole screen. The share is video only — no system or tab audio is requested — and only one background is attached at a time, so choosing an image while a screen is shared replaces it, and vice versa. Finally, this is not a collaborative session: the board is a single-person surface, so what you are sharing is being drawn on by you, on your machine, and travels to other people only through your call software or an exported file.
Four Things Worth Annotating Over
- A live dashboard in a review. Share the tab, circle the metric that moved, draw the trend you are claiming, and let the numbers keep refreshing underneath. Nobody has to squint at a screenshot from yesterday to follow an argument about today.
- A bug you can reproduce but not freeze. Share the window, trigger the behaviour, and mark the moment it goes wrong while it is going wrong. With the screen recording box ticked you hand the developer a video of the actual failure with your arrows on it, not a written description of one.
- Teaching software step by step. Share the app, draw the click path as you talk, then wipe the strokes and do the next step on the same live window. It is the digital version of pointing at someone's monitor, and it suits the same audiences as a full-screen whiteboard for online teaching.
- Design feedback on a running prototype. A prototype is interactive by definition, so a still image loses the thing you are reviewing. Share it, click through it, and annotate each state as you reach it.
Start With One Screen and One Arrow
There is not much to learn here, which is the point. Open the board app, click Share my screen, choose a window in the browser's picker, and draw an arrow at something. Turn on clean mode if the toolbar is in the way, and hold Alt when you need it back. If you are going to record, tick the box that includes the screen before you press record rather than after. When you are done, remove the background — or just close the tab, which ends the share and takes the stream with it.
Everything above happens on your own machine: no upload, no account, no stored session, and no copy of your screen left behind, because the screen was never data the board could keep in the first place. If you would rather show a board than a screen, the full-screen whiteboard and the standard online whiteboard pages cover the drawing engine itself, and presenting with a full-screen whiteboard covers the live-audience side of the same tool.