What is Gemini Canvas?

Canvas is a Gemini working surface for generating and iterating on documents, code, and interactive web pages inside the conversation. Web output is typically a self-contained HTML file with its CSS and JavaScript inline.

How do you share something built in Gemini Canvas?

Copy or download the generated code as an HTML file, then upload it to a host that returns a public URL. Anyone with the link can then open and interact with the page in a normal browser.

Why not just share a screenshot of the Canvas output?

A screenshot removes the interaction, which is usually the point of an interactive build. Reviewers cannot click, type, or test responsiveness, so the things most likely to be wrong stay invisible.

Can people comment on a shared Gemini Canvas build?

Not inside Canvas, which is scoped to your own session. Hosting the exported HTML on a platform with on-page commenting lets reviewers pin notes to specific elements on the live page.

Do you need to know how to code to share a Canvas build?

No. Saving the generated code as a file with an .html extension and uploading it is the whole process. No build step, terminal, or hosting configuration is involved for a single-file page.

How to Share a Gemini Canvas Build as a Live Link

Gemini Canvas will generate a functioning interactive page from a prompt, then keep editing it as you talk. What it will not do is let anyone else open it. This guide covers getting a Canvas build out as a live link, and getting reviewer feedback back onto the page itself.

The Problem

Canvas output is scoped to your session. That is a reasonable design for a working surface and a hard stop for collaboration.

The consequences are specific:

Nobody else can interact with it. The build is interactive, and every method of showing it to someone — screenshot, recording, describing it — removes exactly the interactivity that makes it worth reviewing.
The artifact keeps moving. Iterating in Canvas replaces what was there. Whatever a colleague looked at over your shoulder is gone.
Feedback has nowhere to land. Even after a colleague sees it, their note goes into chat, detached from the element it refers to.

The single-file nature of the output makes this frustrating rather than difficult. There is no build step standing between you and a shareable page — the file is already complete.

1. Get the HTML out

Canvas web output is normally one self-contained HTML file with the styles and scripts inline. Copy the code, or download it if the option is offered, and save it locally as something like prototype.html.

Check it works before you send it anywhere: double-click the file. It should open in your browser and behave the way it did in Canvas. If it does, it is portable — a self-contained HTML file has no dependencies to break.

One thing to look for: some generated pages load a library from a CDN. That is fine online and will fail offline, which matters only if a reviewer opens the file from a plane.

2. Host it

A local file is not shareable. Emailing it mostly does not work — mail providers strip or quarantine HTML attachments, and recipients who do get it see raw markup or a security warning rather than the page. Upload the file to a host instead and share the URL.

This is a ten-second step for a single file. Upload, get a link, paste the link.

3. Collect feedback on the page

Once it is a URL, the interesting part becomes where the feedback goes. On Undraft the same link is the review surface: a reviewer clicks any element on the live page and pins a comment to it. The note about the chart legend is attached to the chart legend.

That removes the translation step that consumes review rounds — the one where you read “the label on the left is confusing” and go looking for which label.

Iterating Without Losing the Thread

Canvas is built for fast iteration, which means you will produce several versions of the same page in an afternoon. Two rules keep that from turning into confusion:

One project, many versions. Re-upload each new export to the same project rather than creating a new one. The link you already sent keeps working and points at the latest build, and the earlier builds stay retrievable.

Keep each round’s notes with its round. When feedback is pinned to elements on a specific version rather than scattered across a chat thread, you can still read what was said about version 1 while looking at version 3 — so “did we address that?” has an answer.

Examples

Before

Generate an interactive pricing calculator in Canvas.
Screenshot it into the team channel.
A teammate asks what happens when you enter zero.
You test it, find a divide-by-zero display bug, and fix it.
Repeat for the next question.

Every interactive question costs a round trip through you.

After

Save the Canvas output as calculator.html.
Upload it and share the link.
Teammates try their own edge cases. One enters zero, sees the bug, and pins a comment on the output field.
You re-prompt Canvas, export, and re-upload.
Same link, new version, comment resolved.

Reviewers test their own hypotheses instead of queueing them behind you.

Summary

Export the single HTML file and host it — Canvas output is already self-contained, so sharing needs no build step at all.
Keep one link and version the uploads — a stable URL means you never have to explain which of four links is current.
Avoid sharing interactive work as static images — the bugs that matter only appear when a reviewer can click.

Next: the full guide to share an HTML file as a live link, and how to comment on a webpage once it is hosted.