DEV Community: mdgd

Google Docs to Obsidian: Import as Clean Markdown

mdgd — Thu, 17 Sep 2026 13:15:00 +0000

You have a Google Doc, maybe shared notes, a spec, or a draft someone sent you, and you want it in your Obsidian vault as a proper Markdown note. There are a few ways to do this, and they differ mostly in how much cleanup you are left with afterward. Here are the options from fastest to cleanest, what each one gets wrong, and what to do when the Doc keeps changing after you import it.

The fast way: native export

Google Docs can export Markdown directly:

Open the Doc.
Click File, then Download, then Markdown (.md).
Move the downloaded .md file into your Obsidian vault folder.

That is the quickest route and it needs no add-ons. It handles headings, emphasis, lists, and links well. The catches: tables and some structure do not round-trip cleanly, images are not pulled into your vault as attachments, comments are not carried over, and you get no control over the output style or front matter.

Cleaner conversions, compared

If the native export leaves too much cleanup, these are the common alternatives:

Method	Handles well	Leaves you with	Best for
File, Download, Markdown	Headings, lists, links	Table and image cleanup	A quick one-off import
Docs to Markdown add-on	Headings, lists, links	Tables as HTML, fixed syntax	People already using the add-on
Google Doc to Markdown tool	Inline formatting, no install	Manual image handling	A clean browser conversion
Pandoc via .docx	High structural fidelity	Non-native styling, manual steps	Batch or scripted conversion

The Docs to Markdown add-on is popular but outputs tables as HTML rather than Markdown table syntax, which is awkward inside a Markdown vault. Pandoc gives the best structural fidelity but the round trip through .docx leaves styling to tidy up. For a no-install conversion, the Google Doc to Markdown tool covers most content in the browser. There is a fuller walkthrough in how to convert a Google Doc to Markdown cleanly.

Handling images, tables, and front matter

A few things always need attention when a Doc lands in Obsidian:

Images. Native export does not save images as vault attachments. Download them from the Doc separately and place them in your attachments folder, then fix the links.
Tables. Check every table after import. This is where all the methods struggle most.
Front matter. Obsidian works best when a note has YAML front matter for tags and metadata. No export adds this, so you add it by hand or with a template.

The catch: import is a one-time copy

Every method above produces a snapshot. It is correct the moment you export and stale the moment anyone edits the Doc again. That is fine for a document that is finished, and a problem for one that is not:

The Doc is a shared, living document your team keeps editing.
You want your vault to reflect the latest version without re-exporting.
You also edit the note locally and want those edits to show up in the Doc.

In those cases you are back to exporting and re-importing by hand, and reconciling changes yourself. The conversion is easy; keeping the two copies in agreement is the actual work.

Keeping a Doc and a vault note in sync

The alternative to re-exporting is two-way sync: the Google Doc stays a real, shareable Doc that people comment in, the note stays a Markdown file in your vault, and edits flow both directions automatically.

That is what md2gd does. You keep the Doc your collaborators already use, your vault gets a live Markdown copy instead of a stale export, and you stop re-downloading the file every time it changes. If the Doc you are importing is one that keeps evolving, sync is what turns a one-time import into a note that stays current. It fits naturally alongside Obsidian, which is the better home for the writing while Google Docs stays the place for review.

FAQ

How do I convert a Google Doc to Markdown for Obsidian?
Use File, then Download, then Markdown (.md) and move the file into your vault. For cleaner output, use the Google Doc to Markdown tool or the Docs to Markdown add-on, then check tables and images.

Does Google Docs export Markdown natively?
Yes. Since 2024 you can download a Doc as a .md file directly. It handles most inline formatting but does not preserve tables reliably, does not save images as attachments, and does not carry comments.

Why do tables break when I import a Google Doc into Obsidian?
Google's export and the common add-ons do not map Doc tables to Markdown table syntax reliably; the add-on outputs HTML instead. Review and fix tables after any import.

Can I keep an Obsidian note in sync with a Google Doc?
Not with export alone, since it produces a static copy. md2gd provides two-way sync so the note and the Doc stay current with each other automatically.

The short version

For a finished document, download it as Markdown and drop it in your vault, then fix tables, images, and front matter. For a document that keeps changing, a one-time import goes stale fast, and two-way sync is what keeps your vault note and the Google Doc in agreement. Start with the free tools for the conversion itself.

How to Keep Markdown and Google Docs in Sync (Two-Way)

mdgd — Tue, 15 Sep 2026 13:15:15 +0000

Most people who search for a way to move Markdown into Google Docs are not looking for a converter. They are looking for a converter for the second time. They pasted the Markdown last week, someone edited the Doc, they changed the Markdown, and now the two have drifted apart. A one-time conversion is a snapshot, and a snapshot is out of date the moment either side changes. This post is about the thing you actually want when the same document keeps moving back and forth: two-way sync between a Markdown file and a genuine Google Doc.

Why a one-time conversion never stays in sync

Converting is a copy. Whether you paste Markdown into a Doc or export a Doc back to Markdown, you produce a new artifact that has no connection to the original. From that instant there are two documents, and every edit on either side widens the gap between them.

The workarounds all have the same shape and the same failure:

Re-paste every time. Fast for one edit, miserable as a habit, and it silently discards any changes made on the other side.
Pick a winner and re-export. Declaring one side authoritative and regenerating the other throws away real edits made on the loser.
Reconcile by hand. Diffing two documents by eye is exactly the manual work you were trying to avoid.

If you only need the content in the other format once, a converter is the right tool. Our free tools cover both directions: Markdown to Google Docs and Google Doc to Markdown. The point of this post is what to do when "once" turns into "again," and then "again."

What two-way sync actually means

Two-way sync makes the Google Doc a live view of the Markdown file rather than a copy of it. You link a local .md file to a specific Doc once. After that:

Edit the Markdown in your editor and the Doc updates.
Edit the Doc in the browser and the Markdown file updates.
Neither side is a lossy import artifact. The Doc stays a real, native Google Doc with comments, suggestions, and the mobile app, and the Markdown stays a plain file with full history in git.

Nobody copies content back and forth, and there is no second version quietly going stale. That is the difference between converting and syncing: a conversion ends, a sync keeps running.

How the sync stays sane: block by block

The naive version of sync, replacing the whole Doc whenever the file changes, would stomp on anyone editing the Doc at the same time. Real two-way sync works at the level of blocks (a paragraph, a heading, a list item, a table) rather than the whole document. Non-overlapping edits on the two sides simply both land: you rewrite the intro in your editor while a reviewer fixes a typo in section three, and both changes survive.

The only genuinely hard case is when both sides change the same block between syncs. That needs a defined rule instead of a guess. In md2gd the Doc wins and your local version is set aside as a diff you can inspect, so nothing is silently lost. You run a resolve step to keep either side or hand-merge. The important property is that a conflict is surfaced and preserved, never overwritten in the dark.

One-time convert versus two-way sync

Concern	One-time convert	Two-way sync
What it produces	A fresh copy	A live link between two documents
Stays current	No, stale on the next edit	Yes, both sides track each other
Edits on the other side	Lost on re-convert	Merged block by block
Source of truth	Ambiguous, two versions	The Markdown file
Google Doc	An import artifact	A genuine native Doc
Right when	You need the content once	The same doc keeps moving

When you need sync, and when you do not

Reach for a converter when the job is genuinely one-off: a colleague sends you a Doc and you want it as Markdown, or you have a finished README you want to drop into a Doc once and never touch again. There is no reason to link files you will not edit again.

Reach for sync when the same document lives in two places at once and both keep changing. Common cases:

A spec or PRD written in Markdown that non-engineers need to review and comment on in a Doc. This is the docs-as-code review loop, covered in depth in Docs-as-Code With Google Docs in the Review Loop.
Notes or documentation you draft in a Markdown editor but share with a team that lives in Google Docs.
Content generated as Markdown by an assistant that a human then reviews in a Doc, covered in Let AI Agents Write to Google Docs Your Team Reviews.

If you are unsure whether the formatting even survives the trip, Google Docs Markdown: what works, what breaks walks through which elements convert cleanly in each direction.

Getting started

The mental model is one command to link, then nothing. You point the client at a local Markdown file and pair it with a new or existing Doc:

md2gd add spec.md --create

From there both sides are live. Agents and editors keep working on the .md file, people edit and comment in the Doc, and edits flow both ways in the background. You can list what is linked at any time:

md2gd ls

That is the whole workflow. There is no dashboard to babysit and no export step to remember, because the sync is the feature, not a button you press.

FAQ

Can Google Docs stay in sync with a Markdown file automatically?
Not on its own. Google Docs can import and export Markdown as a one-time conversion, but it does not keep an external .md file and a Doc matched over time. Ongoing two-way sync is what md2gd adds.

Is a synced Google Doc still a normal Doc?
Yes. Sync keeps it a genuine native Google Doc with full comments, suggestions, sharing, and the mobile app, rather than a lossy import.

What happens if both the Markdown and the Doc change the same paragraph?
That is the one case that needs a rule. The Doc wins and your local version is preserved as a diff to resolve, so no edit is lost silently. Non-overlapping edits on the two sides both land automatically.

Do I have to move my whole workflow into a new app?
No. You keep your Markdown editor and your Google Docs. Sync runs from a small local client and gets out of the way.

The takeaway

If you have converted the same document more than once, you do not have a conversion problem, you have a sync problem. A converter produces a snapshot that is stale on the next edit. Two-way sync keeps a Markdown file and a real Google Doc matched, block by block, so you stop re-pasting and nothing drifts. Start with the free tools when you need a one-off, and link the file with md2gd when "once" turns into "again."

Obsidian vs Google Docs: An Honest Comparison

mdgd — Thu, 10 Sep 2026 13:15:00 +0000

Obsidian and Google Docs get compared as if you have to pick one, but they were built for different jobs. Obsidian is a local, file-based Markdown knowledge base. Google Docs is a cloud document you share and edit with other people. Most people who ask which is better actually want the strengths of both. Here is an honest comparison, who each tool is for, and how to work across the two without living in a copy-paste loop.

The short answer

	Obsidian	Google Docs
Storage	Local Markdown files you own	Google's cloud
Format	Plain-text Markdown	Proprietary document model
Best at	Personal notes, linking, long-term knowledge	Real-time collaboration and review
Collaboration	Limited, add-on based	Native, real-time, comments and suggestions
Sharing	Manual export or paid publish	A link anyone can open
Works offline	Yes, fully	Limited
Cost	Free for personal use	Free with a Google account

Obsidian is the better place to write and keep knowledge. Google Docs is the better place to share a document with people who just want to read and comment. Neither replaces the other cleanly.

Where Obsidian wins

You own the files. Your notes are Markdown files in a folder on your disk, not rows in someone's database. You can back them up, put them in git, and read them in any editor.
Linking and structure. Backlinks, tags, and the graph view are built for connecting ideas over time, which is a different activity from writing one document.
Speed and offline. It is a local app, so it is fast and works with no connection.
Extensible. A large community plugin ecosystem covers everything from Kanban boards to citations.
Privacy. By default nothing leaves your machine.

This makes Obsidian a strong fit for developers, researchers, and writers who want a durable, private, plain-text home for their thinking.

Where Google Docs wins

Real-time collaboration. Several people edit the same document at once, and you see cursors move.
Comments and suggestions. Reviewers can leave a comment or a tracked suggestion without touching your text. This is the feature that keeps teams on Google Docs.
Sharing is a link. Anyone with the link can open the document, no install and no account setup.
Non-technical reviewers. A manager or client who has never heard of Markdown can open a Doc and start commenting immediately.
Mobile and ubiquity. It runs anywhere and most teams already use it.

This makes Google Docs the default for anything that has to be reviewed or co-written with other people.

The real friction: moving between them

The problem shows up the moment your Obsidian note needs a human review. You paste it into a Google Doc and the formatting falls apart: headings might survive, but tables become a row of pipes and code blocks keep their backticks. Google Docs added a native Markdown paste in 2024, but it still drops tables, code, and comments, and it only runs one direction.

Going the other way is just as lossy. Exporting a Google Doc back to Markdown for your vault loses table formatting and does not preserve comments. We cover the cleanest paths for that in Google Docs to Obsidian.

For a one-time move, the free converters handle most of it:

Markdown to Google Docs to turn a note into a clean Doc, tables included.
Google Doc to Markdown to pull a Doc back into your vault.

You do not have to choose

The either-or framing is the mistake. The setup that holds up is to keep writing in Obsidian, where your Markdown lives, and share the same content as a real Google Doc when it needs review, with changes flowing both ways.

That is what md2gd is built for. Your note stays a Markdown file you own, the shared version stays a genuine Google Doc your reviewers can comment and suggest in, and edits made on either side sync to the other. You keep Obsidian's local files and git history, your reviewers keep the full Google Docs experience, and nobody pastes content back and forth. If your work starts in Obsidian but has to be reviewed by people who live in Google Docs, that is the workflow to reach for. It is the same pattern teams use for docs-as-code with Google Docs in the review loop.

FAQ

Is Obsidian better than Google Docs?
For personal notes, linked knowledge, and owning your files, Obsidian is better. For collaboration, comments, and sharing with non-technical people, Google Docs is better. They serve different purposes, so many people use both.

Can Obsidian collaborate in real time like Google Docs?
Not natively in the same way. Obsidian's collaboration options are add-on based and aimed at smaller groups. Google Docs is built for real-time multi-person editing, which is why documents that need review tend to end up there.

How do I share an Obsidian note with someone who uses Google Docs?
Convert it with Markdown to Google Docs for a one-time share, or use two-way sync so the note stays a Markdown file while the shared copy is a live Google Doc.

Does pasting from Obsidian into Google Docs keep formatting?
Basic headings and emphasis usually survive, but tables and code blocks break. Enable Markdown paste in Google Docs or convert the note first for a clean result.

Which should you use?

Use Obsidian to write and keep knowledge, and use Google Docs to collaborate and get feedback. The tension only appears when the same content has to live in both, and that is a sync problem, not a reason to abandon either tool. Start with the free conversion tools for one-off moves, and use two-way sync when the same document keeps changing in both places.

Let AI Agents Write to Google Docs Your Team Reviews

mdgd — Tue, 08 Sep 2026 13:15:00 +0000

AI coding assistants and agents write Markdown. It is their native output for a spec, a design doc, release notes, or a report. The people who need to read and sign off on that output rarely live in Markdown. They live in Google Docs, where they can comment, suggest, and share with one link. So on every run there is a handoff: take the agent's Markdown and get it in front of humans in a Doc, then get their feedback back to the agent. This post is about making that handoff a background sync instead of a manual re-paste on every iteration.

The re-paste tax on every agent run

The obvious workflow is also the painful one. The agent regenerates the document, you paste the Markdown into a Google Doc, people comment, you read the comments, you feed them back to the agent, the agent regenerates, and you paste again. Every loop pays a tax:

Re-pasting on each run. A converter is fine once. On the tenth regeneration it is a chore, and it is easy to paste a stale version.
Lost review context. Each fresh paste can blow away the comments and suggestions reviewers left on the previous version, so the discussion resets.
Two drifting versions. The agent's latest Markdown and the Doc people actually edited are never quite the same document.

If the paste itself is what breaks (headings flattening, code blocks mangling), that is a separate and common problem covered in Why AI-Generated Markdown Breaks When Pasted Into Google Docs. This post assumes the paste works and asks the next question: why paste at all, every single run?

Keep agents on local Markdown

There is a temptation to have the agent write directly to the Google Docs API. It is usually the wrong move. Round-tripping every draft through a document API makes each iteration slower, ties the agent to network calls and quota, and spends tokens describing document structure the agent does not need to reason about. Agents are fastest and cheapest when they read and write plain .md on disk.

So keep the division of labor clean:

The agent stays local. It reads and writes a Markdown file, with no Google round-trips in its loop.
The humans stay in Google Docs. They review, comment, and suggest in a real Doc with the tools they already use.
Sync is the bridge between them. The generated Markdown and the reviewed Doc stay matched without either side changing how it works.

The loop, closed by sync

Link the agent's output file to a Doc once, and the iteration loop closes itself:

The agent writes or regenerates the Markdown file locally.
Two-way sync pushes the changes into the linked Google Doc, block by block, without disturbing the parts reviewers are working on.
Reviewers comment and edit in the Doc, exactly as they would with any shared document.
Their edits flow back into the Markdown file, so the agent's next run starts from the reviewed text, not a stale copy.

No one pastes anything. The agent never has to see Google, and the reviewers never have to see the repo or the terminal. This is the same review-loop idea behind docs-as-code with Google Docs, applied when the author is a machine instead of a person.

Why keep the real Doc

It is worth being explicit about why the target is a genuine Google Doc and not a custom review UI. Reviewers already know Google Docs. They have the comment threads, the suggestion mode, the sharing model, the mobile app, and the notifications. A synced Doc gives an agent workflow a review surface that non-technical stakeholders adopt instantly, because there is nothing new to adopt. The Markdown stays the source of truth for the agent, and the Doc stays the review surface for people, and neither has to compromise.

Naive paste versus synced agent output

Concern	Paste on each run	Synced agent output
Effort per iteration	Manual re-paste every time	None, sync runs in the background
Reviewer comments	Reset on each paste	Persist on the living Doc
Agent speed and cost	API detours or repeated paste	Agent stays on local `.md`
Feedback to the agent	Copied back by hand	Flows back into the Markdown
Versions	Markdown and Doc drift	One document, two views

Fitting it into an automation

The same pattern holds when the agent is part of a pipeline rather than an interactive session. If a scheduled job or an automation step (the kind you might wire in n8n or a CI task) regenerates a Markdown artifact, syncing that file to a Doc means stakeholders always see the latest version at the same link, and their edits are waiting in the Markdown for the next run. The automation writes files, sync handles the Doc, and no step in the pipeline needs to speak the Google Docs API.

Getting started

Point the client at the file your agent writes and pair it with a Doc:

md2gd add report.md --create

Then let the agent do its thing. Each run updates the file, the linked Doc tracks it, and reviewer edits come back into the file for the next iteration. When you just need a one-off paste rather than an ongoing loop, the Markdown to Google Docs tool covers it, and Paste to Markdown handles the reverse. For the recurring case, that is what md2gd is built for, and there is more on the underlying model in How to Keep Markdown and Google Docs in Sync.

FAQ

Can an AI agent write directly into a Google Doc?
It can through the Google Docs API, but that makes every iteration slower and more expensive and couples the agent to network calls. Having the agent write local Markdown and syncing that to a Doc keeps the agent fast and the Doc native.

Do reviewer comments survive when the agent regenerates the document?
With two-way sync, yes. Sync updates the Doc block by block instead of replacing it, so comments stay attached rather than being wiped by a fresh paste.

How do the reviewers' edits get back to the agent?
Edits made in the Doc flow back into the linked Markdown file, so the agent's next run starts from the reviewed text.

Does this need the agent to change how it works?
No. The agent keeps reading and writing plain .md files. Sync runs separately, in a small local client.

The takeaway

Agents write Markdown and people review in Google Docs, and the gap between those two facts is usually filled with manual re-pasting on every run. It does not have to be. Keep the agent on local Markdown, keep reviewers in a real Doc, and let two-way sync carry edits both ways so the loop closes on its own. See how the sync works for the model, and md2gd for the tool.

How to Sync an Obsidian Vault With Google Drive

mdgd — Thu, 03 Sep 2026 13:15:00 +0000

People switch to Obsidian and then hit the same question: my notes live on my laptop, so how do I get them into Google Drive, or in front of someone who works in Google Docs? The answer starts with understanding what an Obsidian note actually is.

Your vault is just a folder

An Obsidian vault is not a database or a proprietary file format. It is a plain folder on your disk. Every note is a .md text file you could open in any editor. Images and PDFs you drop in are saved as ordinary files next to your notes. The only Obsidian-specific piece is a hidden .obsidian folder that stores your settings and plugins.

This is the whole reason Obsidian is portable. There is no export step, because the files were never locked up in the first place. Copy the folder to another machine and you have your entire vault. If Obsidian disappeared tomorrow, your notes would still open in any text editor.

It also means one practical thing: syncing your vault is the same problem as syncing any folder. Whatever keeps a folder in step across machines will keep your vault in step.

Putting a vault on Google Drive

Google Drive for desktop

The simplest approach is Google Drive for desktop. Add your vault folder to the set of folders Drive mirrors, and it uploads changes as you save them. For a single-machine backup, this is fine.

A few things to watch:

Drive syncs files as-is. A .md file lands in Drive as a .md file. You cannot open it as a Google Doc and comment on it. It is just a text file sitting in Drive.
Editing on two machines at once produces conflict copies. If your laptop and desktop both save the same note before Drive catches up, you get a second file with a conflict suffix, and you merge them by hand. The hidden .obsidian folder is a common trigger, because plugins write to it constantly.
Mobile is the weak spot. The Drive app on your phone does not hand those files to Obsidian mobile in a way that just works, so a phone usually needs extra tooling.

A community sync plugin

Several community plugins back a vault up to cloud storage. If you want your vault on Drive and you are comfortable configuring a plugin, this is an option. Check the plugin's current list of supported backends before you commit, since they change often, and test a throwaway vault first.

Obsidian Sync

Obsidian's own paid Sync service is the least-fuss way to keep a vault matched across your own devices, phone included. It does not use Google Drive; it is Obsidian's own storage. Worth knowing it exists, but it is a different thing from "my notes in Drive."

The gap all of these leave

Every option above treats your note as a file to copy. None of them turn it into something the rest of your team can work in. If you write in Obsidian and someone asks you to drop a note into a Google Doc so they can comment, you are back to copy-paste and manual reformatting.

That is the specific problem md2gd solves. It keeps a Markdown note and a real Google Doc in sync both ways. You keep writing in Obsidian. Your reviewer opens a normal Google Doc, leaves edits, and those edits come back to your Markdown. It stays a real Doc, not a .md file parked in Drive, so sharing and commenting work the way people already expect. There is also a CLI, so if an agent is generating notes in Markdown, it can create and update the Doc directly.

To sync an entire vault, one shell command links every Markdown note to its own Google Doc:

find ~/MyVault -name '*.md' -exec md2gd add {} --create \;

That walks the whole vault, subfolders included, and creates a linked Doc for each note. Edits then flow both ways. For a single note, run md2gd add "Meeting Notes.md" --create, or use --pick to link a Doc that already exists.

A few limits to be upfront about: images are not supported yet, the Google Docs to Markdown direction runs on about a one minute delay, and there is a cap of ten syncs per account for now.

Which one to pick

If you just want a backup of your vault, Drive for desktop or a sync plugin does the job. If you want your own notes on all your devices, Obsidian Sync is the least fuss. If the point is to get an Obsidian note in front of people who live in Google Docs without losing your Markdown, that is where two-way sync earns its keep.

Why AI Markdown Breaks in Google Docs

mdgd — Tue, 01 Sep 2026 13:15:00 +0000

You asked an assistant for a spec, a PRD, or a README, and it gave you a clean answer. Then you pasted it into Google Docs to share with your team, and the table collapsed into a row of pipes and the code block became a wall of backticks. This is not a bug in your prompt. It is the predictable result of pasting Markdown into a tool that only converts part of it. Here is what actually breaks, the reason, and how to paste agent output so the structure holds.

Why your AI outputs Markdown

Claude, ChatGPT, and Gemini all format their responses in Markdown by default. It is compact, unambiguous, and renders nicely in a chat window. That is great until the destination is Google Docs, because assistant output leans hard on exactly the elements Docs handles worst: tables for comparisons, fenced code blocks for snippets, and inline code for names and commands.

What breaks on paste

With a plain paste, or even with Google's "Paste from Markdown" enabled, the same elements fail consistently:

Tables. Pipe-delimited tables usually stay as literal text, one line of pipes per row.
Fenced code blocks. Triple-backtick blocks keep their backticks and render as plain text instead of a code block.
Inline code. Backtick spans are not converted.
Task lists and blockquotes. These are dropped or left as raw syntax.

The basics do survive: bold, italic, headings, and simple links map onto Docs styles and come through fine. So the paste looks half-right, which is what makes it confusing.

Why it breaks

A Google Doc is a structured document model, not a text renderer. A table in a Doc is a real table element with rows and cells. A line like | Method | Result | is just characters, and there is no automatic rule that turns those characters into that table element unless a converter builds the structure first. Inline styles such as bold have an obvious one-to-one mapping, so they survive. The structural elements have no such mapping, so they fall back to raw text.

Google's 2024 "Paste from Markdown" feature widened what converts, but it still does not guarantee tables or code blocks. Treat it as a help, not a fix.

How to paste agent output cleanly

There are two clean paths, depending on what you have:

The output is raw or mixed (some Markdown, some rich text pasted from elsewhere). Run it through paste to Markdown first to normalize it into clean Markdown. Everything runs in your browser, so nothing is uploaded.
You want it as rich text in the Doc, tables and all. Convert the Markdown to formatted content with Markdown to Google Docs, which preserves tables that a plain paste would flatten.

Either way, the move is to convert before you paste, not to fight the paste after.

Paste methods, compared

Method	Tables	Code blocks	Effort
Plain paste (Ctrl/Cmd V)	Lost	Lost	None, but lossy
Paste from Markdown (built-in)	Usually lost	Often lost	Toggle a setting
Convert first, then paste	Preserved	Preserved	One extra step

When you paste the same content repeatedly

If an agent regenerates the Markdown on every run and you keep re-pasting it into the same Doc, the paste step is not the real problem, the copying loop is. Keeping a Markdown file and a Google Doc in sync both ways removes the loop entirely: the agent writes Markdown, the Doc stays a live document your team can comment in, and neither drifts from the other. That is what md2gd does.

For the full picture of what Google Docs supports and where it breaks, see Google Docs Markdown: what works, what breaks. For the reverse direction, see how to convert a Google Doc to Markdown.

FAQ

Why does ChatGPT or Claude output look broken in Google Docs?
Assistants emit Markdown by default, and Google Docs' paste only converts a subset of it. Tables, fenced code blocks, and inline code render as raw characters because a Doc is a structured model with no automatic mapping from those symbols.

Does "Paste from Markdown" fix the problem?
It helps with headings, lists, and links, but it still does not reliably convert tables or code blocks. Converting the Markdown before pasting is the reliable path.

How do I paste an AI table into Google Docs?
Convert the Markdown to rich text first with Markdown to Google Docs, which preserves the table structure a plain paste would flatten.

How do I clean up messy agent output before pasting?
Run it through paste to Markdown to normalize mixed or raw content into clean Markdown, entirely in your browser.

The short version

Your assistant is not producing bad output. It is producing Markdown, and Google Docs' paste only understands part of Markdown. Convert before you paste, with paste to Markdown to clean it or Markdown to Google Docs to preserve tables. And if the same content keeps flowing from an agent into the same Doc, stop pasting and start syncing.