Google Docs to Substack: How to Copy Without Losing Formatting

Most Substack writers draft in Google Docs. It is free, collaborative, and familiar. You write your post, run a quick spell check, then copy the whole thing and paste it into Substack.

And then you spend the next thirty minutes fixing everything that broke.

Images disappear. Footnotes vanish. Tables look wrong. Extra line spacing appears between every paragraph. Indentation shifts. Comments and suggestions are gone entirely. The post you carefully formatted in Google Docs is now a mess that needs manual cleanup before you can hit publish.

This is not a Substack bug. It is a fundamental mismatch between how Google Docs stores content and how Substack's editor consumes it. Some things transfer cleanly. Many do not. Here is a complete breakdown of what survives, what breaks, and the best workarounds available today.

What Survives the Copy

The good news first. Basic formatting makes it through the paste intact. If your newsletter is mostly text with simple formatting, Google Docs to Substack works fine.

• Bold and italic text. These transfer reliably. If you bold a word in Google Docs, it shows up bold in Substack.
• Headings. H1, H2, and H3 headings carry over correctly. Substack maps them to its own heading styles.
• Basic lists. Bullet points and numbered lists transfer. Simple single-level lists paste without issues.
• Links. Hyperlinks survive. The link text and URL both make it through.
• Block quotes. Quoted text transfers and Substack renders it with its own block quote styling.

If your newsletter only uses these elements, you can stop reading. Copy-paste will work. But most writers use more than bold text and bullet points.

What Breaks: Images

This is the biggest problem. When you paste from Google Docs into Substack, your images disappear or show as broken placeholders.

The reason is technical but simple. Google Docs does not embed images in the document. Instead, it stores references to files on Google's CDN servers. When you copy-paste, the clipboard contains HTML with image URLs pointing to lh3.googleusercontent.com or similar Google domains. Substack cannot access these URLs. They require authentication. The images simply fail to load.

Even when an image does appear briefly after pasting, it often breaks later. Google's CDN URLs are temporary. They expire. A newsletter that looked fine when you pasted it will show broken images when subscribers open it a week later.

The workaround: Download every image from Google Docs manually (right-click, "Save to Keep" or "Download"). Then upload each one individually into Substack's editor. For a post with ten images, this takes five to ten minutes of tedious clicking.

Alternatively, use Google Docs' "Download as HTML" option (File > Download > Web Page). This creates a ZIP file containing the HTML and all images as separate files. You still have to upload each image into Substack individually, but at least you have the files on your computer.

What Breaks: Footnotes

Google Docs has a proper footnote system. You insert a footnote, a superscript number appears in the text, and the note shows at the bottom of the page. Academics, researchers, and longform writers depend on this.

Substack does not support footnotes natively. When you paste from Google Docs, the superscript numbers either disappear entirely or paste as plain text. The footnote content at the bottom of the document either vanishes or pastes as regular body text with no connection to the reference numbers.

The workaround: Convert footnotes to inline parenthetical references before copying. Or use Substack's own footnote feature (which is limited compared to Google Docs) and manually recreate each note. Neither option is fast.

What Breaks: Tables

Tables partially transfer. A simple table with text in each cell will usually paste into Substack. But the formatting degrades. Column widths reset to equal spacing. Cell background colors disappear. Merged cells break. Any table with complexity beyond basic rows and columns will need manual fixing.

Substack's table support is limited to begin with. It does not offer the same formatting controls as Google Docs. Even if the data transfers, you cannot style the table the way you had it.

The workaround: For simple data tables, paste and accept the simplified formatting. For complex tables, take a screenshot in Google Docs and insert it as an image in Substack. You lose the ability for readers to select text from the table, but the visual layout stays intact.

What Breaks: Spacing and Indentation

Google Docs and Substack handle paragraph spacing differently. Google Docs uses configurable line spacing and paragraph spacing (the gap between paragraphs). Substack uses its own fixed spacing rules based on its CSS.

When you paste, extra blank lines often appear between paragraphs. This happens because Google Docs encodes paragraph breaks as separate HTML elements with spacing properties. Substack interprets some of these as additional empty paragraphs.

Indented text also loses its indentation. Google Docs lets you indent paragraphs with the ruler or the tab key. Substack does not support custom indentation. Pasted content snaps to the left margin.

Nested lists (a sub-list inside a list item) sometimes flatten to a single level. You had a carefully structured outline with two or three levels of nesting. After pasting, it is all one level.

The workaround: After pasting, scroll through the entire post and delete extra blank lines manually. For indentation, you are out of luck. Substack does not support it. Restructure your content to avoid relying on indentation.

What Breaks: Code Blocks

If you write about programming or include code snippets in your newsletter, Google Docs is already a poor choice. It has no native code block feature. Most people fake it by changing the font to a monospace typeface and adding a background color.

When pasted into Substack, this fake code formatting either disappears (the font reverts to Substack's default) or the background color strips away. The code becomes indistinguishable from regular text.

The workaround: Use Substack's built-in code block feature after pasting. Copy your code separately and insert it into a Substack code block. This is another manual step for each snippet.

What Gets Stripped Entirely

Several Google Docs features produce zero output in Substack. They do not break or degrade. They simply vanish.

• Comments. All comments and reply threads are stripped. If your editing workflow depends on comments (collaborator feedback, notes to self), none of it transfers.
• Suggestions. Google Docs' suggestion mode (tracked changes) does not transfer. Accepted suggestions are fine because they are part of the document text. But pending suggestions disappear.
• Bookmarks and internal links. Google Docs lets you link to specific sections within the document via bookmarks. These links break in Substack because the bookmark anchors do not transfer.
• Page breaks. Google Docs is page-oriented. Substack is not. Page breaks are ignored.
• Custom fonts. Any fonts you used in Google Docs revert to Substack's default typeface. Typography choices do not survive.

The "Docs to Markdown" Add-on Workaround

The most reliable workaround is the Docs to Markdown Google Workspace add-on. It converts your Google Doc into clean markdown or HTML. You install it from the Google Workspace Marketplace, run it on your document, and it outputs the content in your chosen format.

Here is the workflow:

1. Install the "Docs to Markdown" add-on from the Google Workspace Marketplace.
2. Open your finished Google Doc.
3. Run the add-on (Extensions > Docs to Markdown > Convert). Choose HTML output.
4. Copy the generated HTML.
5. In Substack, open the post editor. Use the embed block or switch to HTML view. Paste the HTML.

This produces much cleaner output than a direct copy-paste. The HTML is semantic and minimal. Headings, lists, bold, and links all render correctly. Images are still referenced by URL, so you still need to re-upload them. But everything else is significantly better.

The downside: you are adding a conversion step to every publishing session. Write in Docs, convert with the add-on, paste HTML into Substack, re-upload images, review the result. For a weekly newsletter, this process gets old fast.

Why Google Docs Is the Wrong Drafting Tool for Newsletters

Google Docs was built for documents, not web publishing. It stores content in a proprietary rich-text format optimized for printing on paper. Page margins, page breaks, headers and footers. These concepts do not exist in email newsletters or web posts.

Every time you copy from Google Docs to Substack, you are converting between two incompatible formats. The clipboard does its best, but "its best" still means broken images, lost footnotes, and extra spacing. No amount of workarounds will fix this completely. The formats are different. The conversion will always be lossy.

This is the same class of problem described in our guide on ChatGPT to Google Docs formatting. Different source, same issue: format mismatches cause predictable breakage.

The question is not "how do I make the paste work better?" The question is "should I be drafting in Google Docs at all?"

The Real Fix: Draft in Markdown, Export Clean HTML

The cleanest path from draft to published newsletter is: write in markdown, export as HTML, paste into Substack. No conversion layer. No add-ons. No manual image re-uploading.

Markdown is a plain text format that converts to HTML deterministically. A ## Heading always becomes <h2>. A **bold** always becomes <strong>. There is no ambiguity. The conversion is lossless because both formats represent the same structure.

Modern markdown editors give you the same visual editing experience as Google Docs. You see formatted text, not raw syntax. Bold text looks bold. Headings look like headings. Lists are indented with bullet points. But under the hood, the document is stored as markdown, which means exporting to clean HTML is trivial.

Athens is built on this principle. You write in a WYSIWYG markdown editor. Images are embedded directly in the document, not referenced from an external CDN. When you export, the HTML output is clean and semantic. Substack accepts it without any of the formatting problems described above.

Athens also has AI editing built in. Instead of switching between Google Docs and ChatGPT (then fighting with both tools' formatting), you edit directly in the document. The AI shows you inline diffs of what it changed. You accept or reject each edit. Your formatting never breaks because the AI operates on the same markdown source.

If you want a broader view of drafting tools designed for newsletter workflows, see our guide on the best Google Docs alternatives with AI.

What About Ghost?

Ghost is the main Substack alternative that supports markdown natively. If you draft in markdown and publish on Ghost, there is no format conversion at all. You paste markdown directly into the Ghost editor and it renders correctly.

Ghost is a strong choice if you are willing to self-host or pay for Ghost Pro. It gives you full control over your publication, supports custom themes, and has a cleaner content model than Substack. The tradeoff is that you lose Substack's built-in discovery network and reader community.

For writers committed to Substack specifically, Ghost is not the answer. But it is worth knowing that the formatting problem is a Substack limitation, not a universal one.

Quick Reference: What Transfers and What Does Not

Here is a summary for quick reference.

Transfers cleanly: bold, italic, strikethrough, headings (H1-H3), basic bullet lists, numbered lists, hyperlinks, block quotes.

Transfers partially: simple tables (formatting degrades), nested lists (may flatten), horizontal rules.

Does not transfer: images (CDN references break), footnotes, comments, suggestions, bookmarks, internal document links, custom fonts, indentation, page breaks, code blocks (if faked with font changes).

The Practical Workflow

If you insist on drafting in Google Docs, here is the least painful workflow:

1. Write your draft in Google Docs as usual.
2. When ready to publish, run the "Docs to Markdown" add-on and export as HTML.
3. Paste the HTML into Substack's editor.
4. Download all images from the Google Doc and re-upload them into Substack one by one.
5. Manually recreate any footnotes using Substack's footnote feature.
6. Scroll through the entire post and fix spacing issues.
7. Preview the post before publishing.

If you want to skip steps two through six, draft in a markdown editor that exports clean HTML with embedded images. Try Athens and publish to Substack without the formatting fight. For more options, see our guide on the best writing apps for Substack.