TL;DR: ChatGPT canvas prompts work best once you know two things OpenAI documents: what actually opens a canvas (roughly 10+ lines, or an explicit ask), and that canvas itself is being folded into inline writing and code blocks for current models. Below is what's true today, plus 25+ scoped-edit prompts organized by job (tightening, restructuring, code review) and the inverse for when you genuinely want a full rewrite.
What is ChatGPT Canvas, and is it still there?
Canvas launched as a side panel. OpenAI's Model Release Notes describe the October 3, 2024 debut plainly: "We trained GPT-4o to collaborate as a creative partner. The model knows when to open a canvas, make targeted edits, and fully rewrite." "Canvas is in early beta, and we plan to rapidly improve its capabilities." For roughly two years, that side panel was the feature: a document or code file opened next to the conversation, and you edited it there instead of pasting a wall of text back into chat.
That changed for current models. The same Model Release Notes page, in the entry dated May 28, 2026, states: "With this update, canvas will no longer be available in GPT-5.5 Instant or GPT-5.5 Thinking. Writing and coding functionality is now supported directly in chat responses through writing blocks and code blocks. Paid users can continue using canvas for a limited time through legacy models until those models are sunset." GPT-5.6 Sol, OpenAI's flagship reasoning model, began rolling out July 9, 2026, after that change and not before it, so the newest default experience for most paid users runs on the writing-block and code-block model, not the classic panel.
Practically, this means the honest answer to "what is Canvas" depends on which model opened your conversation. On a legacy model, you may still get the side panel described below. On GPT-5.5 Instant, GPT-5.5 Thinking, or later, you get inline writing blocks and code blocks instead: same underlying idea, different surface, different documented controls. The prompting discipline in this guide works for both; the mechanics differ, and I'll flag which is which.
What actually opens a canvas or a block?
This is the part every other guide on this topic guesses at. OpenAI's archived canvas explainer (Wayback capture, July 20, 2026) documented the trigger directly: "ChatGPT may open a canvas when it grasps what you’re trying to accomplish." "You can typically expect ChatGPT to open a canvas automatically when ChatGPT generates content greater than 10 lines or detects a scenario where it would be helpful to have an interface for writing or code." It also documented three explicit ways to force one: typing "use canvas…" in your prompt, opening the composer's tools menu and selecting Canvas, or typing a backslash and the canvas command. For a blank start, the same page names the phrases "open a canvas" or "open a coding canvas".
For the current writing-block and code-block surface, OpenAI's help article "Working with writing blocks and code blocks in ChatGPT" documents the trigger differently and gives example prompts directly: "When ChatGPT creates text that you are likely to revise or reuse, it may place the draft in a writing block." Its own suggested prompts to try: "Draft a reply email to my manager." "Write a short Slack update for my team." "Turn these notes into a one-page document." For code, the same article says ChatGPT "usually places code in a code block" whenever it's writing code at all, and there's no stated line-count threshold for code the way there is (or was) for canvas prose.
1. Force a canvas explicitly (legacy models)
Use canvas for this. Draft a one-page project brief for the Q3 onboarding
redesign: goal, scope, timeline, and open questions.
2. Ask for a writing block by naming the artefact (current models)
Draft a reply email to a client who asked for a deadline extension. Keep it
under 150 words and end with a specific next step, not just "let me know."
3. Start from nothing
Open a coding canvas. I want to build a small CLI tool for renaming files
by a pattern — nothing else yet, just an empty starting point.
What can it hold, and what are the editing controls?
Content types and controls differ by surface, and conflating them is where most guidance goes stale.
| Feature | Classic canvas (legacy models) | Writing & code blocks (current models) |
|---|---|---|
| Where it lives | Separate panel beside the chat | Inline inside the chat response |
| Prose editing | Highlight text or use the block-comment icon; basic markdown only | Select the block and edit directly, or ask ChatGPT to revise it |
| Named shortcuts | Suggest edits, Adjust length, Change reading level, Add final polish, Add emojis | None named; you ask in plain language |
| Code actions | Add logs, Add comments, Fix bugs, Port to a language, Code review; runs Python only | Copy, edit, Preview (HTML, React, SVG, Mermaid, Vega/Vega-Lite), run supported Python |
| Version control | Arrow-based version history plus a Show changes diff view | Undo/redo on recent AI-assisted edits; no stated diff view |
| File output | Download to PDF, Markdown, or Word for docs; matching extension for code | Save supported document drafts to Library; share a read-only link for supported code |
On the classic side, the archived canvas explainer is specific about the editing motions: "Additionally, you can select part of the content by highlighting the text or use the block comment icon to select an entire paragraph block. This will open an input where you can provide guidance on what to explain or edit in the selected section." Two named shortcuts, Suggest edits and Review code, add inline suggestion cards with their own Apply button, so you can accept a change without retyping it yourself.
On the current side, the writing-blocks article documents a shorter, plainer list: select the block and edit text directly, copy it, ask ChatGPT to revise the selection or the whole draft, open a full-screen editing view, undo or redo recent AI-assisted edits, and, where available, send an email draft directly or save a document draft to your Library. Code blocks add a Code/Preview toggle for supported content (HTML, React, SVG, Mermaid diagrams, Vega and Vega-Lite charts) and a Run action for supported Python, with console output shown below the block. Neither article documents a general-purpose diff view for the new blocks the way classic canvas's Show changes button does.
One caveat OpenAI states directly, worth carrying into how you save work: "Edits to supported writing blocks and code blocks save with the conversation after a short delay." "In Temporary Chat, edits may not persist after the conversation ends." If you're editing in Temporary Chat, download or copy out anything you want to keep.
Is it on every plan?
Not by a single published rule, and the two documented sources measure different things. The archived canvas explainer stated sharing specifically: "Sharing a canvas is available for all plans including Free, Plus, Pro, Team, Enterprise, and Edu." That's about who can share a canvas once one exists, not a statement that every plan gets the same model, and therefore the same editing surface, by default.
For the current writing-block and code-block system, OpenAI is explicit that there's no fixed table: "Available actions vary by plan, device, workspace settings, model, and rollout." And separately, for the GPT-5.6 Sol rollout that followed the canvas change: "GPT-5.6 Sol is rolling out to eligible paid ChatGPT plans. Free, Go, and logged-out users are not included." Put together, the honest answer is: which editing surface you see, and which actions are available inside it, depends on which model your account is currently running; check your own model picker rather than trusting a number that was accurate in 2024.
On relation to Projects: OpenAI's Capabilities Overview documents Projects as a separate feature: "Projects let you organize chats, files, and context under a shared objective", listed adjacent to canvas on the same page, with no stated integration between the two. Since a canvas or block lives inside an ordinary conversation, and a Project is a container of ordinary conversations, nothing published suggests they conflict — but that's an inference from how the two features are described, not a documented behavior, and I'm labeling it as such rather than asserting it.
Why re-describing the whole thing gives you something different
This is the craft point, and it holds regardless of which surface you're in.
When you ask for a change by restating what you want, you haven't asked for a change; you've written a new specification, and ChatGPT builds against the new one. The heading style you liked, the tone you'd already nailed down three turns ago, the one paragraph you'd deliberately left blunt: none of it is protected, because nothing you said this time referenced it. The document still looks fine. It's just not the same document, and you often don't notice until you compare it against what you had.
The fix is naming the one thing that moves and stating explicitly that the rest holds. This is the same discipline documented for Claude's equivalent workspace: see prompting Claude artifacts, which publishes its own four-part trigger, applied here with ChatGPT's specific shortcuts and block mechanics instead. It's also the same reason your coding assistant sometimes rewrites files you never mentioned touching, a failure mode covered on its own in why AI rewrites code you didn't ask it to touch.
4. The targeted change
Change only the second paragraph's tone to be more direct. Do not touch the
opening, the closing, the structure, or any other paragraph. Everything else
should read identically to the current version.
5. The change budget
I want exactly three changes to this document and nothing else:
1. Shorten the intro to two sentences.
2. Turn the middle list into a table.
3. Fix the date in the third paragraph to Q4 2026.
Do not rephrase anything outside these three items.
6. The freeze list, stated before you touch anything
Before you change anything: list the parts of this draft that are already
working and that I want protected. I'll confirm the list, then treat every
item on it as frozen unless I say otherwise.
Tightening a draft without losing what it says
Cutting length is the shortcut most people reach for first, and it's also the one most likely to quietly drop a caveat you meant to keep. Classic canvas names this explicitly as Adjust the length, with a slider from Shortest to Longest; the current block system has no named equivalent, so you ask directly.
7. Cut length, keep every claim
Cut this to about 60% of its current length. Every factual claim currently
in the draft must still appear somewhere in the result, even if reworded.
Tell me if a cut forces you to drop a claim rather than doing it silently.
8. The sentence-level pass
Go sentence by sentence. For each one, either keep it, cut it, or merge it
with a neighbor — no rewriting a sentence's meaning, only its length.
Show me which sentences you cut and why.
Changing register without changing what it says
A register change and a content change are different requests, and asking for one while meaning the other is how "make it more casual" turns into a document that's shorter, friendlier, and missing a paragraph.
9. Formality only
Make this less formal. Do not add information, do not remove any claim, and
do not reorder sections. If a sentence can't be made less formal without
changing its meaning, leave it exactly as is and tell me which ones.
10. Reading-level pass with a stated floor
Adjust the reading level down to roughly a Grade 8 level, the same way the
"Change reading level" shortcut would, but do not simplify any number,
date, or named entity — those stay exact even if the surrounding sentence
gets simpler.
Restructuring without a rewrite
Reordering is the one that tempts a full re-describe the most, because it's tempting to just paste the content back in a new order. Ask for the move instead.
11. Reorder, content untouched
Reorder these three sections so the timeline comes first, then the summary,
then the risks. Do not change a single sentence inside any section — this
is a move, not a rewrite.
12. Promote a subsection to its own section
Pull the "budget" subsection out from under "Scope" and make it its own
top-level section between "Scope" and "Timeline." Leave its wording as is.
Expanding one section, and only that one
Asking for "more detail" without a boundary is how a two-paragraph edit becomes a five-paragraph document that no longer matches the rest of the draft's density.
13. Expand with a stated ceiling
Expand only the "Risks" section to include two more concrete examples.
Cap it at 120 words. Do not touch any other section, and match the
sentence rhythm already used in the rest of the document.
14. Add the missing "why," not new claims
The "Timeline" section states what happens but not why the order matters.
Add one sentence per milestone explaining the dependency, and nothing else.
Do not add new milestones.
Code review and refactor in a code canvas
Classic canvas names five code shortcuts directly: Add logs, Add comments, Fix bugs, Port to a language, and Code review. Some of these (Add comments, Port to a language, Fix bugs) update your code immediately when you use them; Code review instead returns inline suggestions you accept individually, the same way Suggest edits works for prose. The current code-block system covers the same ground through plain-language requests plus a documented Run action for supported Python, with console output shown below the block, and a Preview toggle for HTML, React, SVG, Mermaid, and Vega/Vega-Lite content.
15. Code review scoped to one concern
Do a code review of this function for one thing only: error handling on
bad input. Ignore style, naming, and performance for this pass. List each
gap with the line number.
16. The equivalent of "Port to a language," stated explicitly
Port this function from Python to TypeScript. Keep the same function
signature in spirit, the same error behavior, and the same variable names
translated to camelCase. Do not add features the Python version doesn't have.
17. Fix bugs without a refactor
Fix only the bug where an empty list causes a crash on line 12. Do not
rename anything, do not reorganize the file, and do not touch any other
function.
18. Add logs for one debugging session
Add temporary debug logging around the retry loop only — log the attempt
number and the error on each failure. Mark these as temporary so I remember
to remove them, and don't add logging anywhere else in the file.
19. Run and diagnose, don't fix yet
Run this and show me the console output. If it errors, tell me what the
error means and where it likely originates, but don't change any code
until I confirm which fix I want.
Adding or removing a section
Deletion is the edit most likely to take collateral damage with it, because a section rarely exists in total isolation from a cross-reference two paragraphs later.
20. Remove a section, check for orphaned references
Remove the "Appendix B" section entirely. Then check the rest of the
document for any sentence that refers to it, and list those sentences
separately — don't edit them yet, just flag them.
21. Add a section in the house style
Add a new "Rollback plan" section between "Deployment steps" and "Owners."
Match the heading style, sentence length, and level of formality already
used in the rest of the document. Do not touch any existing section.
Adjusting for a different audience
Same facts, different assumed knowledge, and the trap is softening the harder version into vagueness instead of translating it.
22. Two audiences, same facts
Produce two versions of this incident summary: one for the engineering
team, one for customers. Same dates, same root cause, same resolution.
Where the engineering version names a specific component, the customer
version should name the consequence to them, not just say "an issue."
23. Explain a term without cutting it
Rewrite this for someone outside the industry. Every technical term that
matters to the outcome must stay in the text, with a short in-line
explanation the first time it appears. Do not simply remove the term.
A final proofread pass
The closest thing to classic canvas's Suggest edits and Add final polish shortcuts, described in plain language for either surface.
24. Suggest edits without applying them
Go through this and suggest edits for clarity, grammar, and consistency
only. Do not change the structure, the tone, or any factual claim. Show
each suggestion separately so I can accept or reject them one at a time.
25. The diff-style check before you ship it
Compare this against the version from three edits ago. List what changed,
grouped as: things I asked for, things that changed as a side effect, and
anything that changed for no reason I gave you.
The inverse: asking for a full rewrite on purpose
Sometimes a full rewrite is exactly what you want, and forcing a scoped edit onto a draft that's fundamentally wrong just wastes turns preserving a structure that should be thrown out. The difference is deciding that on purpose, not defaulting to it because re-describing felt faster.
26. The deliberate full rewrite
Ignore everything about the current draft's structure. Rewrite this
completely from the brief below, as if the existing draft didn't exist.
Brief: [paste the actual goal, audience, and constraints here]
27. Salvage before you discard
Before you rewrite this from scratch, pull out anything from the current
draft that's genuinely worth keeping — a phrase, a specific number, a
structural choice — into a short list. Then rewrite using that list where
it fits, and tell me what you couldn't reuse.
Honest limits: running well isn't the same as correct
A code block that executes without an error, or a document that reads smoothly, has cleared a much lower bar than "correct." Running only proves the code didn't throw on the inputs you happened to try. It says nothing about a duplicate entry, an empty upload, a negative number, a date that crosses a year boundary, or text in a script the model handled less carefully during testing. Reading smoothly says nothing about whether a fact survived ten rounds of "just tighten this a bit more."
That second failure is easy to miss because nothing announces it. Ask for a tenth small edit and you can end up further from your original voice and your original facts than when you started, with no single step that looks wrong. The habit that actually protects you: keep the original draft saved somewhere untouched (copied out, downloaded, or kept in your own prompt library) before you start iterating, so "closer to what I meant" has a fixed point to be measured against instead of just "different from ten edits ago." Follow-up prompts that actually improve the answer covers the same drift risk from the conversational side.
28. Ask for the edge cases before you trust it
List every input that would break this — empty fields, duplicate entries,
extreme values, non-English text. For each one, tell me what happens now
and whether that's the behavior I'd actually want. Don't fix anything yet.
Where this fits in a prompt library
None of the templates above are single-use. The targeted-change prompt, the freeze list, and the edge-case check are the three you'll reach for on every canvas or block edit you ever make, and retyping them from memory each time is exactly how they degrade into "make it better."
Save them with the variable parts marked, so the section name, the word-count cap, and the frozen list swap out per document. Prompt Architects does this with variables and a shared library, and the extension runs directly on chatgpt.com, including inside canvas and the composer, so the enhanced prompt lands where you're already typing. The free plan includes 5 prompt enhancements per day, forever, according to our FAQ page. We generate the prompt; ChatGPT builds the canvas, or the block.
For more on getting past beginner-level prompting in ChatGPT specifically, see advanced ChatGPT prompting for people past the basics.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 4.8★ on the Chrome Web Store.
Create An AccountSources
All OpenAI pages accessed September 2, 2026, via curl -L --http1.1 with a desktop Chrome user agent (help.openai.com blocks plain HTTP/2 requests but serves HTTP/1.1 normally).
- Model Release Notes, OpenAI Help Center (live, includes the October 2024 canvas launch and the May 28, 2026 GPT-5.5 Instant update):
https://help.openai.com/en/articles/9624314-chatgpt-canvas - Working with writing blocks and code blocks in ChatGPT, OpenAI Help Center, updated August 2026:
https://help.openai.com/en/articles/20001246-working-with-writing-blocks-and-code-blocks-in-chatgpt - ChatGPT Capabilities Overview, OpenAI Help Center, updated August 2026 (live; its own canvas explainer link 404s):
https://help.openai.com/en/articles/9260256-chatgpt-capabilities-overview - What is the canvas feature in ChatGPT and how do I use it?, OpenAI Help Center — returned HTTP 404 on September 2, 2026; quoted from a Wayback Machine capture dated July 20, 2026:
https://web.archive.org/web/20260720213323/https://help.openai.com/en/articles/9930697-what-is-the-canvas-feature-in-chatgpt-and-how-do-i-use-it