Normal chat is good for turns. Canvas is better for artifacts. When the work is a thing you want to shape over multiple passes, a workspace built around the artifact can be more natural than a thread built around messages.
Most people discover canvas by accident -- it opens automatically when they ask for something long enough. But treating canvas as a random event rather than a deliberate choice means missing most of its value. The real power of canvas is not that it displays text in a side panel. It is that it separates two concerns that chat conflates: the artifact you are building and the conversation about how to build it.
Show a split between conversation guidance and a working artifact living in canvas.
- What kinds of work benefit from canvas.
- How canvas changes revision behavior.
- How to think about artifact-centered workflows.
This matters because many people keep large drafting and revision tasks in plain chat longer than they should. That can make the work feel fragmented and harder to inspect. When a draft lives inside a chat thread, every revision attempt produces a new message. To compare versions, you scroll up and down. To check whether a structural change actually helped, you hold both versions in your head while switching between messages. This works for a paragraph. It does not work for a two-page report or a 200-line function.
Canvas is useful when the output itself needs sustained attention. That applies to essays, outlines, plans, code, and other artifacts that benefit from visible iteration.
It also matters for collaborative work. When multiple people need to see, edit, or comment on the same artifact, a shared canvas provides a single source of truth. Chat threads are personal by nature. Canvas artifacts can be shared, exported, and reviewed in formats that fit into existing team workflows.
Finally, canvas matters for code work. Iterating on code in chat means each version appears as a new code block, and comparing versions requires scrolling or opening a separate diff tool. Canvas keeps the code in place and lets you revise it incrementally, which makes multi-step refactoring and debugging significantly smoother.
The core idea
Use canvas when the artifact matters more than the exchange. The chat remains useful, but its job shifts toward steering, critique, and revision guidance rather than holding the entire workflow in message form.
For writing, canvas supports cleaner passes such as outlining, drafting, restructuring, and polishing. For code, it can help when you want the code itself to remain visually central while you iterate on logic or structure.
The distinction is worth understanding mechanically. In normal chat, the artifact and the conversation are the same object. Every revision produces a new message, and the previous version scrolls away. That is fine for short, disposable outputs. But when the artifact is something you want to improve through several rounds -- a report, a strategy document, a function with edge cases -- scrolling through interleaved messages becomes a poor editing environment. Canvas separates the artifact from the conversation so each one can do its job without interfering with the other.
This separation also changes how you think about revision. In chat, many people issue a single rewrite instruction and accept whatever comes back. In canvas, the artifact stays visible, so you naturally start thinking in passes: fix the structure first, then tighten the language, then check the tone. That sequential discipline is not something canvas forces on you, but the interface makes it far more natural than chat does.
How it works
- Move into canvas when the deliverable is longer or more persistent than a normal answer. Canvas auto-opens for content longer than about 10 lines or for complex writing and coding tasks. You can also trigger it manually by saying "use canvas."
- Use the chat or prompt space to request specific revision moves rather than vague improvement. Name the dimension you want improved: "tighten the argument in section two" is better than "make it better."
- Treat each pass as purposeful: structure, clarity, compression, tone, or correctness.
- After each pass, review the changes using Show Changes. If a pass made things worse, use version history to revert before continuing.
- When the artifact is ready, export it in the format your workflow needs -- PDF for stakeholders, Markdown for documentation, or a code file for your repository.
Availability: Canvas is available to all users, including the Free tier, on web, Windows, and macOS (since December 2024).
Features worth knowing
- Version history: The top toolbar includes navigation arrows and a "Show Changes" view that highlights deletions in red and additions in green. Use this to review what changed across passes.
- Sharing and collaboration: Canvas supports sharing with other users for real-time viewing, interaction, and editing.
- Export options: Export canvas content to PDF, Markdown, Word (.docx), and code-specific formats (.py, .js, etc.).
- Code toolbar shortcuts: When working with code, the toolbar offers quick actions for reviewing code, adding logs, adding comments, and fixing bugs.
- Inline editing: You can select specific text or code within the canvas and ask ChatGPT to revise just that selection, leaving the rest untouched. This is more precise than asking for a full rewrite and prevents the kind of collateral changes that can lose good material.
- Direct editing: You can also type directly into the canvas to make manual changes yourself, then ask ChatGPT to continue working from your edits. This hybrid approach -- human edits plus AI assistance -- often produces better results than either approach alone.
What skilled users do differently
A less experienced user opens canvas, pastes a draft, and says "make it better." The result is a full rewrite that may or may not preserve the parts that were already strong. They accept the output because it sounds polished, without checking whether the structure actually improved.
A skilled user treats canvas as a revision workbench. They name the pass before they start: "first, fix the section order so the argument builds logically." Then they review the diff using Show Changes before moving on. They run a second pass for tone, a third for compression. Each pass has a purpose, and the version history lets them revert if a pass made things worse. The result is not just a better draft -- it is a revision process they can repeat and teach to others.
For code work specifically, skilled users lean on the toolbar shortcuts to add logs, comments, or bug fixes without leaving the canvas. They treat the code artifact as the primary object and use the chat side for questions like "what edge cases does this miss?" or "refactor the error handling to use early returns." The conversation informs the artifact rather than replacing it.
Two worked examples
Example 1: a vague canvas request
Help me improve this draft in canvas.
This prompt has the same weakness as asking a colleague to "make this better" without saying what is wrong. Canvas will produce a rewrite, but it will guess which dimensions matter: structure, tone, length, audience, or all of them at once. The result may change things that were already working.
The deeper problem is that this prompt encourages a single-pass rewrite. Canvas is designed for iterative revision, but a vague instruction like this gives it no reason to break the work into stages. You get one shot at improvement instead of a sequence of targeted passes.
Example 2: a structured revision specification
Use canvas as an editing workspace for this article draft.
Revision sequence:
1. identify the structural weaknesses
2. propose a cleaner outline
3. revise for clarity and compression
4. keep the tone calm and professional
Do not rewrite everything at once. Work in passes and explain the purpose of each pass briefly.
This version works better because it breaks revision into named passes with clear purposes. It also sets an explicit constraint -- do not rewrite everything at once -- that prevents the kind of wholesale replacement that loses good material.
Notice that the prompt does not mention canvas features like version history or Show Changes. It does not need to. What it does is shape the revision process itself. The tooling follows naturally once the process is clear.
Example 3: a code revision in canvas
Use canvas for this Python function. I need three revision passes:
1. First pass: fix any bugs and handle the edge case where the input list is empty.
2. Second pass: improve readability -- better variable names and clearer logic flow.
3. Third pass: add type hints and a concise docstring.
Show changes after each pass. Do not refactor the overall approach unless there is a clear reason.
def process(d):
r = []
for i in d:
if i > 0:
r.append(i * 2)
return r
This example shows canvas applied to code rather than prose. The same principle applies: named passes, each with a clear purpose, and an explicit constraint against unnecessary refactoring. The Show Changes feature lets you verify that each pass did only what was asked, which is especially important for code where a well-intentioned "improvement" can introduce subtle bugs.
Prompt block
Help me improve this draft in canvas.
Better prompt
Use canvas as an editing workspace for this article draft.
Revision sequence:
1. identify the structural weaknesses
2. propose a cleaner outline
3. revise for clarity and compression
4. keep the tone calm and professional
Do not rewrite everything at once. Work in passes and explain the purpose of each pass briefly.
Why this works
The better prompt treats canvas as a revision environment with named passes, which is closer to how serious editing actually works. Professional editors do not attempt to fix everything simultaneously. They make a structural pass, then a clarity pass, then a tone pass, because each dimension requires different attention. When you give canvas the same discipline, the revision quality improves and you can use the version history to evaluate whether each pass actually helped. This also makes the process teachable: you can hand someone the same pass sequence and they will get similar results.
- Using canvas like a normal one-shot chat response.
- Trying to rewrite a whole artifact in one pass when the real problem is structural.
- Forgetting to define what kind of revision the workspace should support.
- Never checking version history or Show Changes, so you cannot tell what improved and what regressed.
- Using canvas for short, disposable outputs that do not need a persistent workspace, adding friction without benefit.
- Ignoring the export options and manually copy-pasting content out of canvas, which can lose formatting or introduce errors.
- Choose one draft or code artifact you already have.
- Open it in canvas and run three named passes: structure, clarity, and polish.
- After each pass, use Show Changes to review what was altered.
- Compare the final result to what you would have gotten from a one-turn chat rewrite.
- In one sentence, name the pass that made the biggest difference and explain why.
Do not skip step five. Identifying which revision pass mattered most trains your eye for what to prioritize in future editing sessions.
When to stay in chat instead
Not every task needs canvas. Short, disposable outputs -- a quick rewrite of a subject line, a one-paragraph explanation, a list of five ideas -- are better served by normal chat. The overhead of a workspace is only worth it when the artifact will be revised, shared, or used as a working document. If you would not save the output to a file, you probably do not need canvas.
Similarly, tasks that are primarily about conversation -- brainstorming, Q&A, decision exploration -- belong in chat or voice. Canvas adds value when the deliverable is a thing, not when the deliverable is understanding.
A useful rule of thumb: if you expect to ask for more than two revision passes, open canvas. If you expect to use the output once and move on, stay in chat.
The same principle applies to code. If you need a quick utility function generated from a description, chat is fine. If you are iterating on a more complex piece of code -- refactoring for readability, handling edge cases, improving error messages -- canvas keeps the code visible and the revision history accessible. That visibility is what makes multi-pass code improvement practical.
One common gray area: outlines and plans. These are artifacts, but they are often short and disposable. If your outline is a quick sketch that you will revise once and then move on from, chat is fine. If the outline is a structural backbone that you will iterate on before building a larger document from it, canvas is the better choice. The decision depends on how much revision the artifact will need, not on its length.
Canvas is strongest when the artifact is the center of gravity and the conversation becomes a steering layer around it.