DEV Community: mdgd

Markdown to Word (.docx): The Options Compared

mdgd — Thu, 01 Oct 2026 13:15:00 +0000

You wrote it in Markdown, and the person who needs it wants a Word document. A .docx is still the default currency for anything that gets reviewed, tracked-changed, or emailed to someone outside engineering. There are four solid ways to get from Markdown to .docx, and they trade off install effort against control. Here is each one and how to choose.

The four ways to convert

Pandoc. The command-line standard for document conversion. Most control, needs installing.
A VS Code extension. Convert from the editor you already write Markdown in.
An online converter. Upload or paste, download a file. Convenient, with a privacy caveat.
A browser tool. Paste Markdown and download a .docx locally, nothing uploaded.

Pandoc

Pandoc is the reference tool for this. The command is short:

pandoc input.md -o output.docx

It handles headings, lists, tables, code blocks, and footnotes, and it can apply a reference .docx so the output matches your organization's styles:

pandoc input.md --reference-doc=template.docx -o output.docx

The output is a real Word document that opens in Microsoft Word, Pages, and Google Docs. The cost is setup and the command line, which pays off for repeatable or scripted conversions and is more than you need for a single file.

A VS Code extension

If you draft Markdown in VS Code, an export extension keeps you in one place. Most route through Pandoc under the hood, so you still install Pandoc, but you trigger the conversion from the command palette instead of the terminal. Good if you convert often and already live in the editor; the fidelity is essentially Pandoc's.

An online converter

Paste or upload Markdown, download a .docx. This is the least effort and needs nothing installed. The trade-off is privacy: your content is sent to and processed on someone else's server, so it is a poor fit for anything confidential. Formatting fidelity varies by service, with tables and code blocks the usual place to check.

A browser tool

For a no-install conversion that keeps the content on your machine, paste your Markdown into Markdown to Word, name the file, and download a .docx that opens in Word, Pages, and Google Docs with formatting preserved. It runs fully in the browser, so nothing is uploaded, which makes it a better fit for private content than a server-side converter.

The options, compared

Method	Fidelity	Install	Privacy	Best for
Pandoc	High, style templates	Yes, plus CLI	Local	Repeatable or scripted jobs
VS Code extension	High (Pandoc-backed)	Yes	Local	Frequent conversion while writing
Online converter	Varies	None	Sent to a server	A quick, non-sensitive file
Browser tool	Good, in-browser	None	Local	A private, no-install one-off

When Word is only the handoff format

Converting to .docx is the right call when someone needs a Word file once. It gets repetitive when the Markdown keeps changing and each change means another export and another email attachment, with no clear record of which version the reviewer actually saw.

If the review happens in Google Docs rather than Word, there is a way to skip the export loop: keep the Markdown as your source of truth and sync it to a real Google Doc that reviewers comment in, both directions. That is what md2gd does, and it is the subject of docs-as-code with Google Docs in the review loop. For the Google Docs side of Markdown specifically, see what works and what breaks.

FAQ

How do I convert Markdown to a Word document?
Pandoc with pandoc input.md -o output.docx is the command-line standard, or paste into a browser tool like Markdown to Word for a no-install .docx download.

Will the .docx open in Google Docs and Pages too?
Yes. A .docx produced by Pandoc or Markdown to Word opens in Microsoft Word, Apple Pages, and Google Docs with formatting preserved.

How do I match my company's Word styles?
Pandoc's --reference-doc=template.docx applies the styles from a reference document to the converted output.

Is it safe to use an online Markdown to Word converter?
Server-side converters send your content to a third party, so avoid them for confidential material. A browser tool like Markdown to Word keeps the content on your machine.

Which should you use?

For a one-off, a browser tool gives you a clean .docx with nothing installed and nothing uploaded. For repeatable jobs or strict style requirements, Pandoc, on its own or behind a VS Code extension, is the durable choice. And if the reason you keep exporting is that someone reviews the document and sends edits back, consider whether the review belongs in a synced Google Doc instead of a chain of Word attachments.

Google Docs Markdown: What Works and What Breaks

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

You pasted your AI assistant's output into Google Docs, and half of it fell apart. The headings survived and the bold text made it, but the table turned into a row of pipes and the code block is now a wall of backticks. This is the most common Markdown-in-Google-Docs problem, and it has a clear explanation. Here is what Google Docs actually supports today, where it breaks, how the common workarounds compare, and how to set up a workflow that keeps a Markdown file and a real Google Doc in sync instead of copying between them forever.

Does Google Docs support Markdown?

Partially, and it depends on which feature you use. In July 2024, Google Workspace added native Markdown import and export to Google Docs. Together with the older autocorrect behavior that converts a few symbols as you type, that gives you three separate paths, each with different coverage. All of them are off by default.

To turn Markdown handling on, open Tools, then Preferences, and enable "Enable Markdown" (see how to enable Markdown in Google Docs for the full walkthrough and fixes when it does not work). After that you get:

Paste from Markdown: copy Markdown text, right-click in the doc, and choose "Paste from Markdown".
Import: open a .md file directly with File, then Open.
Export: download the doc as Markdown with File, then Download, then Markdown (.md).

What converts cleanly

Across the import and paste-from-Markdown paths, the basics are reliable:

Bold, italic, and strikethrough
Headings (the # levels map to Docs heading styles)
Ordered and unordered lists with shallow nesting
Inline links

If your document is mostly prose with some headings and links, the built-in features handle it well.

What breaks

The failures are consistent, and they are the parts that matter most for technical content:

Tables. Pipe-delimited Markdown tables are the single most common casualty. In the paste path they usually stay as literal text. To build one cleanly, use the Markdown table generator.
Fenced code blocks. Triple-backtick blocks tend to render as text with the backticks still showing, not as a formatted code block.
Inline code. Backtick spans are not converted.
Blockquotes, task lists, and images by URL. These are dropped or left as raw syntax.
Deeply nested lists. Three or more levels convert inconsistently.

There is a reason for this. A Google Doc is a structured document model, not a text renderer. A table is a real table element with rows and cells, so a line of pipe characters has no automatic mapping to it unless a converter builds that structure first. The simple inline styles have an obvious mapping, so they survive; the structural ones do not.

One caveat: the July 2024 import path handles more than the older autocorrect paste, but it still does not guarantee tables, and it does not carry over comments. Treat table support as something to verify on your own documents rather than assume.

Why this bites now: your AI writes Markdown

Claude, ChatGPT, and Gemini all produce Markdown by default. When you paste a generated spec, PRD, or README into Google Docs to share it with your team, you hit every gap above at once, because agent output is exactly the content that leans on tables and code blocks.

Two quick fixes for this case:

To clean up raw or mixed output first, run it through paste to Markdown.
To turn Markdown into rich text that survives the paste, including tables, use Markdown to Google Docs.

The workarounds, compared

Method	Handles well	Breaks	Best for
Autocorrect paste	Bold, italic, some links	Tables, code, most structure	A quick prose snippet
Paste from Markdown	Headings, lists, links	Tables, code blocks	Medium-complexity docs
File, then Open (.md import)	Most inline elements, headings	Tables, comments, images	A one-time import
Docs to Markdown add-on (reverse)	Headings, lists, links	Tables become HTML, fixed syntax	Exporting a Doc to Markdown
Pandoc to .docx, then upload	High structural fidelity	Non-native styling, manual steps	Batch or scripted conversion

A few notes. The Docs to Markdown add-on is the most-used option for the reverse direction, but it outputs tables as HTML rather than Markdown table syntax and gives you little control over the output style. Pandoc gives the cleanest structural fidelity, but the round trip through .docx and Drive leaves you with non-native styling to tidy up (see Markdown to Word: the options compared). For a no-install conversion in the browser, the Markdown to Google Docs and Google Doc to Markdown tools cover both directions.

The real limitation: it is one-way

Every method above produces a static copy. The moment the source changes, the copy is stale. That is fine for a one-time conversion, and painful for anything ongoing:

Your source of truth is a Markdown file in a git repo, and teammates edit the Google Doc.
An AI agent regenerates the Markdown file on every run.
You want comments and edits from the Doc reflected back in your local file.

In all three cases you end up copying in one direction, then the other, by hand. The conversion was never the hard part. Keeping the two copies in agreement over time is.

A workflow that keeps both in sync

The alternative is two-way sync: the Markdown file stays your source of truth in the repo, the Google Doc stays a real, native Google Doc that people can comment and suggest in, and changes flow in both directions. You get git history and clear provenance on the Markdown side, your reviewers get the full Google Docs experience, and nobody is pasting content back and forth.

This is what md2gd is built to do: keep a local Markdown file and a genuine Google Doc in sync, both ways, without turning the Doc into a lossy import artifact. If your work starts as Markdown and needs to live as a shared Google Doc too, sync closes the gap the conversion tools leave open.

Quick reference

Feature	Docs paste / import	Docs to Markdown add-on	Two-way sync
Bold, italic, links	Yes	Yes	Yes
Headings	Yes	Yes	Yes
Tables	Often lost	HTML output	Preserved
Code blocks	Usually lost	Partial	Preserved
Stays in sync after edits	No	No	Yes

FAQ

Does Google Docs support Markdown natively?
Partially. Google Docs can auto-convert basic Markdown such as bold, italic, and some links as you type, and it can import .md files since July 2024. It does not reliably handle Markdown tables, fenced code blocks, inline code, blockquotes, or task lists, which appear as literal characters when pasted.

How do I paste Markdown into Google Docs with tables intact?
Google Docs' native paste does not render Markdown tables. Convert the Markdown to rich text before pasting with a tool like Markdown to Google Docs, which handles tables without any install.

What is the best way to export a Google Doc to Markdown?
Google's built-in File, Download, Markdown works for most content, though tables can lose formatting. The Docs to Markdown add-on is an alternative but converts tables to HTML. For a clean export, try Google Doc to Markdown.

Can I keep a Markdown file and a Google Doc in sync?
Not with the built-in features. Import, export, and Pandoc all create a static copy that goes out of date when either file changes. md2gd is built for two-way sync, so the Markdown stays in your repo and the Google Doc stays a live, editable document.

Why does AI-generated Markdown look broken in Google Docs?
Assistants like Claude, ChatGPT, and Gemini output Markdown by default, and Docs' paste only converts a subset of it. Tables, code blocks, and some headings render as raw characters. Enabling "Paste from Markdown" helps, or convert the output with a tool first.

Which should you use?

If you need a one-time conversion, Google's built-in import or a free converter will get you most of the way, with tables and code blocks as the parts to check. If your Markdown and your Google Doc both keep changing, no amount of converting will keep them together, and two-way sync is the workflow that holds up. Either way, start with the free tools and reach for sync when the copy-paste loop becomes the bottleneck.

How to Convert a Google Doc to Markdown (Cleanly)

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

You have a Google Doc and you need it as Markdown, for a GitHub README, a static site, or an LLM prompt. There are four common ways to do it, and they differ mostly in one place: what happens to tables and to the stray formatting Google Docs leaves behind. Here is each method, what it keeps, what it breaks, and how to pick.

The four ways to convert

Built-in export. File, then Download, then Markdown (.md). Native, no install, and it covers most prose.
The Docs to Markdown add-on. A long-standing community add-on that converts a Doc to Markdown and copies it to your clipboard.
Pandoc. A command-line converter. Highest structural fidelity, but it is a local tool you install and run.
A browser tool. Select all in the Doc, copy, and paste into Google Doc to Markdown. Nothing installs and nothing uploads.

Built-in export

Since Google added Markdown export in 2024, this is the fastest path. Open the Doc, choose File, then Download, then Markdown (.md), and you get a .md file.

It handles headings, bold, italic, lists, and links well. The weak spot is tables: depending on the content they can lose their column structure, so check any table-heavy document after export rather than assuming it survived. Comments and suggestions are not carried over, which is usually what you want in an export anyway.

The Docs to Markdown add-on

The add-on is the most-referenced option for this direction, and it works, with one caveat worth knowing before you rely on it: it outputs tables as HTML rather than as Markdown pipe tables. If your target renders HTML inside Markdown that is fine; if you need portable pipe-table syntax, you will be reformatting by hand. It also gives you little control over the output style.

Pandoc

If you already live in a terminal, Pandoc gives the cleanest structural result. The usual route is to download the Doc as .docx first, then convert:

pandoc input.docx -t gfm -o output.md

gfm targets GitHub-Flavored Markdown, so tables and task lists come through in portable syntax. The cost is the setup: you install Pandoc, export the .docx, and run the command, which is worth it for batch or scripted jobs and overkill for a single document.

A browser tool

For a one-off with no install, select everything in the Doc, copy, and paste into Google Doc to Markdown. It straightens smart quotes, strips the invisible spacing Google Docs adds, and hands back clean Markdown. Everything runs in your browser, so the document text is never uploaded. If you also need the other direction, paste to Markdown cleans formatted text copied from any source.

The methods, compared

Method	Handles well	Breaks or costs	Best for
Built-in export	Headings, lists, links, prose	Tables can lose structure; no comments	A quick, native export
Docs to Markdown add-on	Headings, lists, links	Tables become HTML; little style control	Clipboard-first workflows
Pandoc	Tables, task lists, high fidelity	Install, .docx step, command line	Batch or scripted conversion
Browser tool	Clean inline output, smart-quote fixes	Paste-based, one document at a time	A no-install one-off

When the export keeps coming back

Every method above produces a static copy. That is exactly right for a one-time conversion. It becomes a chore when the Doc keeps changing and you keep re-exporting: a teammate edits the Doc, and your Markdown file is stale again the next morning.

If your Markdown is the source of truth and the Google Doc is where people read and comment, converting on a loop is the wrong tool. Two-way sync keeps a local Markdown file and a real Google Doc in agreement in both directions, which is what md2gd is built for. For the mechanics of what converts and what does not in the other direction, see Google Docs Markdown: what works, what breaks.

FAQ

How do I convert a Google Doc to Markdown?
Use File, then Download, then Markdown (.md) for a native export, or select all, copy, and paste into a browser tool like Google Doc to Markdown for a clean, no-install result.

Does Google Docs export tables to Markdown?
The built-in export can lose table structure on complex tables, and the Docs to Markdown add-on outputs tables as HTML. For portable pipe-table syntax, Pandoc targeting gfm is the most reliable.

What is the cleanest way to convert without installing anything?
Copy the Doc contents and paste into Google Doc to Markdown. It runs in the browser, straightens smart quotes, and removes the hidden spacing Google Docs inserts.

How do I keep the Doc and the Markdown in sync instead of re-exporting?
Exporting always creates a static copy that goes stale. md2gd keeps a Markdown file and a Google Doc synced both ways so you stop re-converting.

Which should you use?

For a single document, the built-in export or a browser tool gets you clean Markdown in seconds, with tables as the thing to double-check. For batch or scripted jobs, Pandoc is worth the setup. And if you find yourself converting the same Doc again and again, the fix is not a better converter but keeping the two in sync. Start with the free tools and reach for sync when the re-export loop becomes the bottleneck.

Docs-as-Code With Google Docs in the Review Loop

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

Docs-as-code treats documentation like source: it lives in git as Markdown, it moves through pull requests, and it ships from the same pipeline as the code it describes. It is a good model, and it has one persistent gap. The people who most need to review a spec, a PRD, or release notes are often not the people who are comfortable in a pull request. This post is about closing that gap by putting a real Google Doc in the review loop without giving up Markdown as the source of truth.

What docs-as-code gets right

Keeping documentation as Markdown in the repository buys you the things you already value in code:

History and provenance. Every change is a commit with an author and a diff.
Review in context. Docs change alongside the code, in the same pull request.
One source of truth. The file in the repo is authoritative, not a copy in someone's Drive.
Automation. The same pipeline that tests code can lint, build, and publish docs.

For an engineering audience, this works well. The friction shows up at the boundary.

Where it breaks: the reviewer boundary

A pull request is a great review surface for engineers and a wall for almost everyone else. When a product manager, a lawyer, or an executive needs to weigh in, "leave a comment on line 42 of the diff" is not a reasonable ask. So the doc gets copied out to a Google Doc for their review, and now there are two versions: the Markdown in git and the Doc people are actually commenting on. Their edits live in the Doc, your source of truth is in the repo, and reconciling the two is manual.

This is the same stale-copy problem you hit with any one-time conversion, just recurring. Exporting to Markdown or pasting into Docs both produce a snapshot that is out of date the moment either side changes. For the details of what converts and what breaks, see Google Docs Markdown: what works, what breaks.

Closing the loop with two-way sync

The fix is to make the Google Doc a live view of the Markdown rather than a copy of it. With two-way sync:

The Markdown file stays your source of truth in the repo, with full git history.
The Google Doc stays a genuine, native Doc, so reviewers get comments, suggestions, and the editing experience they already know.
Changes flow in both directions, so a suggestion accepted in the Doc lands back in the Markdown, and a commit to the Markdown updates the Doc.

Nobody pastes content back and forth, and there is no second version drifting out of date. Your reviewers never have to see the repo, and you never have to leave it. This is exactly what md2gd is built to do.

How this fits an agent workflow

The same loop matters when an agent is the author. If an assistant regenerates a spec as Markdown on each run, and a human reviews it in a Doc, syncing keeps the generated Markdown and the reviewed Doc aligned instead of forcing a re-paste every iteration. The agent writes Markdown, the reviewer stays in Google Docs, and provenance stays intact on the Markdown side.

Copy-paste versus sync

Concern	Copy-paste / export	Two-way sync
Source of truth	Ambiguous, two versions	The Markdown file in git
Reviewer experience	Comments stranded in a copy	Native Google Docs comments
Edits from reviewers	Reconciled by hand	Flow back to the Markdown
Stays current	No, snapshot goes stale	Yes, both sides track each other

Getting started

If your immediate need is a one-time conversion in either direction, the free tools cover it: Google Doc to Markdown for exporting and Markdown to Google Docs for the reverse. If the problem is that the same document keeps moving between a repo and a reviewer, that is the sync case. See also how to convert a Google Doc to Markdown for the export side of the workflow.

FAQ

What is docs-as-code?
Docs-as-code is treating documentation like source code: writing it in Markdown, storing it in git, reviewing it in pull requests, and publishing it from the same pipeline as the code.

Why involve Google Docs at all in a docs-as-code workflow?
Because many reviewers are not comfortable commenting on a pull request. A Google Doc gives them the familiar comment-and-suggest experience while the Markdown stays authoritative in the repo.

How do reviewer edits get back into the Markdown?
With two-way sync, changes made in the Doc flow back to the Markdown file, and commits to the Markdown update the Doc, so neither side goes stale. md2gd is built for this.

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

The takeaway

Docs-as-code is the right home for documentation, and the pull request is the wrong review surface for non-engineers. You do not have to choose. Keep the Markdown as your source of truth and let a synced Google Doc carry the review, so the loop closes itself instead of running through a copy-paste chain. Start with the free tools for one-off conversions, and reach for sync when the same document keeps crossing the boundary.

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.