Obsidian Enhancing Export turns Pandoc into your export backend

Pandoc does the work, the plugin wires it up

obsidian-enhancing-export is an enhancing export plugin based on Pandoc for Obsidian. The framing of the project is that it is the export layer Obsidian does not have, and Pandoc is the engine underneath.

That division of labour is the whole design. The plugin does not implement a document writer. It collects the note, resolves the attachments, builds a Pandoc command line, runs it, and places the result. Everything about how a Markdown document becomes a docx or a LaTeX file is Pandoc's behaviour, and the plugin's job is to make that reachable from a note in a vault.

The list of target formats is given in the project description and repeated in the readme: Markdown, Markdown for Hugo, HTML, docx and LaTeX, and the package description adds ePub and PDF to the set of formats it allows you to export to.

The plugin is a community plugin, so it is installed through Obsidian's own plugin browser, and the readme is bilingual with an English version and a Chinese one linked at the top. The author is credited as YISH in the package manifest.

Only three of the formats are tested on all three systems

The readme carries a note that is worth reading before anything else, because it sets the expectations the author has. The Markdown, Hugo Markdown and HTML formats are tested in Mac OS, Windows and Linux, as the author used it for themselves, and the other formats are not tested well.

So the plugin has a tested core and an untested periphery. If your use case is docx or LaTeX, you are in the second group, and the author says so.

The three tested formats also share a second property: where they export, the media resources go with them. The readme states that Markdown, Hugo Markdown and HTML will export with their media resources together, which is the behaviour that makes the Hugo path usable, since a Hugo site needs the images in a predictable place rather than left behind in the vault.

The plugin is MIT licensed, with the licence in the LICENSE file, and the release history is regular. The versions are 1.11.3 from 2026-08-22, 1.11.2 from 2026-08-21 and 1.11.1 from 2026-02-05, and the last push was on 2026-08-22.

Installation is Pandoc first, then the plugin

The order matters, and the readme is explicit about it. The first step is to install the latest pandoc, version 3.1.9 or newer, and then add the pandoc path to the PATH environment variable, or set the absolute path of pandoc in the plugin setting view.

The readme links to the Pandoc installation page for the details, and the setting-view route is the one that matters for Obsidian, because a desktop app launched from a GUI does not necessarily inherit the same environment as a shell.

The second step is to search for obsidian-enhancing-export in the community plugins of Obsidian and install it.

Two interface points are documented with screenshots. There is the export view, where you click on Export to... on the file menu, and there is the setting view, which is where the Pandoc path goes and where the export templates are configured.

Custom templates, and the variables they can use

The export command is configurable, and the mechanism is a template list in the setting view. You can customize your export command yourself, clicking add in the plugin setting view and then choosing the template custom to add a new configuration.

The custom command can use variable placeholders, and the readme documents them in a table. The output side has ${outputPath}, the output file path after export, ${outputDir}, the output directory of the saved file, ${outputFileName}, the file name without extension, and ${outputFileFullName}, the name with extension.

The input side has ${currentPath}, the path of the currently edited file, ${currentDir}, its directory, ${currentFileName}, the filename without extension, and ${currentFileFullName}, the filename with extension. The vault side has ${vaultDir}, the current Obsidian vault directory, and ${attachmentFolderPath}, the attachmentFolderPath of Obsidian. There is also ${embedDirs}, a string containing the directories of embedded files for use with the --resource-path argument.

The last row is the most interesting: you can use keyword: value pairs in YAML Front Matter and then reference them as ${metadata.keyword}. That means per-note export settings live in the note itself, so one note can export with a different template or a different destination from its neighbours without touching the global configuration.

A plugin that is mostly a template file

The repository layout shows how little of this plugin is code. The substantive part is a single file, src/export_templates.ts, and the readme invites contributions to it directly with a request to welcome more command templates to that path.

Around it there are lua and textemplate directories, which are Pandoc-side assets, a screenshot directory holding the two interface images, a tests directory, a typings directory, and a version.mjs with a versions.json, which is the version bookkeeping for an Obsidian plugin that has to declare a minimum app version.

The build is a Vite build with the dev script watching in development mode, and the tests run under jest with ts-jest. The manifest is a standard Obsidian plugin manifest. The main entry in the package manifest is dist/main.js, and the type is module, so the bundle is an ES module.

The dependency list is small and mostly build-time. The runtime dependencies are semver, solid-js and yargs-parser, with solid-js and vite-plugin-solid suggesting the settings interface is built with Solid rather than with the Obsidian React helper, and yargs-parser for parsing the command arguments that make up an export command. The obsidian package itself is a dev dependency, as it is for any plugin, since it provides the type definitions and is provided by the app at runtime.

What it is for, and what to pair it with

The related resources the project points to give a good sense of who uses it and for what.

The first is a tutorial for academic writing in Obsidian, hosted on betterhumans.pub, which covers setting the plugin up and using it to export to docx, pdf, tex and bib. That is the most specific evidence of the intended audience, and it is not a marketing site article. The output formats listed there, docx, pdf, tex and bib, are exactly the set an academic workflow needs and exactly the set the plugin leaves to Pandoc.

The second is a collection of Lua filters for Pandoc, the pandoc-ext repository, described as filters and other goodies to get the most out of Pandoc. This matters because the plugin's export commands are Pandoc commands, so a Lua filter can be inserted into one of them.

The third is a math LaTeX editor. LaTeX output usually means formulas, and the formula pipeline in Obsidian depends on how the notes are written, so a LaTeX editor is a natural companion rather than an unrelated recommendation.

Taken together, the pattern is a writer who wants Markdown as the working format and a real publishing tool as the output, with the plugin acting as the bridge and Pandoc doing the conversion work.

Editorial conclusion

Adopt obsidian-enhancing-export if you write in Obsidian but need to publish the result as docx, LaTeX or Hugo-flavoured Markdown, since it delegates the conversion to Pandoc instead of shipping its own writer. Do not adopt it if the built-in Obsidian exporter already produces what you need, and do not rely on the untested formats for a deadline. Before you install, check three things: that Pandoc 3.1.9 or newer is on your PATH or its absolute path is set in the plugin settings, that your template is one of the tested ones if you care about output quality, and that you understand the media handling, since only the Markdown, Hugo and HTML exports are documented as shipping their media resources.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mokeyish/obsidian-enhancing-export on GitHub
4. README
5. Releases