Google/Drive/Q/Does Google Drive render relative Markdown links and image embeds?
Does Google Drive render relative Markdown links and image embeds?
- Answer/Official from Use Markdown in Google Docs, Slides, & Drawings, Import and export Markdown in Google Docs, Compose with Markdown in Google Docs on web, and Google Drive API export formats
- Short answer: No.
 does not render on any Google Drive surface, and [text](./other-note.md) never becomes a working link to the sibling file. A relative path needs a base directory to resolve against, and no Drive surface supplies one — Drive's viewer never interprets the Markdown at all, and Google Docs converts an imported file into a standalone document with no memory of the folder it came from. - "Google Drive renders Markdown" describes three different surfaces that behave differently. Answering each separately matters, because only one of them interprets Markdown syntax at all, and even that one is documented not to handle images.
1. File preview in Drive itself
- Relative links: no. Relative image includes: no. Neither is interpreted, because nothing interprets the Markdown.
- Verified — the documentation is silent. Google's file types you can view in Drive covers "videos, PDFs, Microsoft Office files, audio files, and photos" and never mentions Markdown. Use Markdown in Google Docs, Slides, & Drawings routes a
.md file in Drive through Open with > Google Docs rather than any Drive-native rendering. No Google page documents a Markdown renderer in the Drive viewer, and none documents its absence either. - Inferred — Drive shows
.md as raw text. This rests on secondary evidence rather than documentation: browser extensions exist for the sole purpose of fixing it, and describe the default behavior directly. Markdrive states "Google Drive shows .md files as raw text," and Google Drive Markdown Preview exists to render .md in Drive preview mode. If the source is displayed verbatim, the literal characters  appear on screen — the question of resolving the path never arises.
2. Import into Google Docs, and export back out
- Relative links: converted to a hyperlink, but not to the sibling file. Relative image includes: not converted at all.
- Verified — what the syntax list covers. Use Markdown in Google Docs, Slides, & Drawings documents headings (
# through ######), italics, bold, strikethrough, and links in the [text](url) form. The word "image" does not appear anywhere on that page, and neither does any ![...] syntax. The July 2024 announcement that shipped import and export names no supported or unsupported elements at all. - Verified — import is real and is a one-way conversion. File > Open > Upload in Docs, or right-click > Open with > Google Docs in Drive. The result is a Google Doc, not a view of the
.md file. The Drive API export table lists text/markdown (.md) as one of eight Docs export formats, alongside .docx, .odt, .rtf, .pdf, .txt, .epub, and zipped HTML. - Inferred — why a relative link cannot resolve. A converted Doc is identified by a Drive file ID, not by a path within a folder, so
./other-note.md has nothing to be relative to. Google's documentation says nothing about resolving link targets against the source folder or rewriting them to Drive file IDs. Expect the link text to survive with a relative href that goes nowhere useful. - Inferred — images do not come across. The syntax list omits them, and users report the omission as behavior: Google Docs Paste From Markdown Local Images Do Not Paste in the Docs Editors community. A Docs engineer commenting on the Hacker News thread about the launch said only that "Import supports links via upload," which is too thin to build on and appears in no Google documentation. Treat image import as undocumented and unreliable.
- Not documented, but stated publicly by a Docs engineer — the reverse direction inlines rather than references. Exporting a Doc to Markdown produces base64 data URIs, collected as reference-style links at the bottom of the file: "Export outputs base64 encoded image URLs. We use Markdown reference links to place the large URLs out of the way of reading at the bottom of the file." Users in the SilverBullet community report a 16 MB
.md from a single illustrated document. So a round trip never yields a relative ./image.jpg path in either direction — Docs has no concept of a sibling asset file.
3. Markdown pasted into an open Google Doc
- Relative links: same as import — a hyperlink that does not point at the sibling file. Relative image includes: no.
- Verified — the feature and how to turn it on. Enable under Tools > Preferences > Enable Markdown, then right-click and choose Paste from Markdown (Docs Editors Help). The July 2024 post notes that Copy as Markdown and Paste from Markdown ship off by default, while import and export are on. Paste-as-Markdown itself dates to the March 2022 rollout.
- This is the weakest surface for the question, and the reason is structural. A paste has no source file, so there is no folder for a relative path to be relative to — not even in principle. The clipboard carries text;
./elevation-profile.jpg arrives with no way to locate the directory the note came from. - Inferred — images are dropped. Same evidence as import: the documented syntax list has no image form, and the community thread above reports local images failing to paste.
What a directory of notes with sibling images actually needs
- Every option below gives up something. Named plainly:
- Inline the images as base64 data URIs. This is the one embedded-image shape Google's own tooling produces, so it is the form most likely to survive contact with Docs. Cost: file size explodes — the 16 MB single-document report above is the shape of it. The
.md stops being readable or diffable in a plain editor, and Drive's raw-text preview shows you the base64 blob rather than the note. Fixes nothing about Drive preview. - Point images at absolute HTTPS URLs on a host that permits hotlinking. Cost: the vault stops being self-contained, so it no longer survives being copied or archived, and every note breaks if the host does. Drive is a bad choice of host for this: the long-standing
drive.google.com/uc?export=view&id=… embed path now returns 403, and the drive.google.com/thumbnail?id=…&sz=w1000 substitute rate-limits once a page carries many images. - Convert the vault into Google Docs and insert images natively. Cost: you stop having a Markdown vault. Links between notes become Doc URLs maintained by hand, the sibling-file structure disappears, and there is no clean path back. This is the only option that makes images actually render inside a Google surface.
- Use Drive as sync and storage only, and read the vault somewhere that resolves paths. Obsidian, Logseq, VS Code, or a static-site build pointed at a locally synced Drive folder resolves
./elevation-profile.jpg normally, because resolution happens against the real filesystem. Cost: nothing renders in a browser. Anyone holding only a Drive share link still sees raw text, and every machine needs Drive for Desktop or an equivalent sync installed. - Install a browser extension that renders
.md in Drive preview. Cost: it is per-viewer and per-browser, so a shared link renders for you and not for the recipient. Relative image resolution remains doubtful even then, since the extension would have to look up a sibling Drive file rather than fetch a path — do not assume the images appear just because the text does. - Keep the
.md as source and store a rendered artifact beside it. Build to PDF or self-contained HTML with images embedded, and put that in the same Drive folder. Cost: two copies to keep in step, and a build step to run. In exchange, PDF preview in Drive is documented, works for everyone with the link, and needs nothing installed. - If the vault has to stay a vault, the fourth option is the only one that keeps it intact — Drive becomes storage, and rendering moves to a tool that understands directories.