Configuring Pandoc for Verified DOCX and EPUB Exports from Typora

Typora displayed DOCX and EPUB export choices, yet selecting them could not start the converter. The application itself was healthy, and its native output paths still worked. The missing boundary was the external program used for the additional formats.

Typora documents that HTML, PDF, and image output are available directly, while formats such as Word, RTF, and EPUB use Pandoc. Its support guide also recommends restarting the application after installation and selecting the Pandoc executable manually when discovery still fails (Typora export documentation).

This case used a narrow repair: establish the converter state, install Pandoc once, bind the executable explicitly, and verify actual DOCX and EPUB packages. No PDF engine or unrelated Typora configuration was added.

The export menu did not prove the converter was available

The initial checks separated Typora's interface from the process it needed to launch:

• the pandoc command was not resolvable in the current Windows environment;
• Typora recorded a process-start failure for Pandoc;
• the existing advanced configuration file had not been changed;
• native Typora behavior remained available.

That evidence limited the fault to converter discovery. Resetting the editor, replacing themes, or changing document content would have expanded the change surface without addressing the failed process boundary.

Pandoc is an external dependency in this path

Typora hands several import and export formats to Pandoc instead of implementing each converter inside the editor. A visible menu item therefore describes a supported integration, not proof that the external executable is installed and reachable.

This distinction also explains a common post-install symptom. An installer can update the user's executable search path, while an already-running desktop process continues using the environment it inherited when it started. Restarting Typora refreshes that environment. Selecting the executable in Typora's Export settings removes the remaining ambiguity by recording the exact program to launch.

Install one copy and verify the executable

Pandoc's official Windows instructions list both an installer and this exact WinGet package command (Installing Pandoc):

winget install `
  --source winget `
  --exact `
  --id JohnMacFarlane.Pandoc

Use one installation method. The Pandoc documentation warns that mixing package managers can leave multiple installations, which makes path diagnosis less predictable.

After installation, open a fresh PowerShell session and establish what Windows resolves:

Get-Command pandoc
pandoc --version

Record the resolved executable, not a guessed default directory. Restart Typora. If the editor still asks for Pandoc, open Preferences, choose Export > General, and select that resolved executable as the Pandoc path.

The resulting chain should be explicit:

1. Start the Typora export action.
2. Launch the configured or freshly discovered Pandoc executable.
3. Select the requested output format: DOCX or EPUB.
4. Write the generated package.

Verify content, structure, and embedded resources

An export notification is useful operational evidence, but it does not prove that the result retained the document features that matter. The verification document in this case included:

• Unicode text;
• a small table with known values;
• one local image referenced by the Markdown.

It was exported separately to DOCX and EPUB. Both formats are ZIP-based packages, so their internal structure could be inspected without relying on a desktop viewer alone.

For DOCX, the checks confirmed the document XML, expected text and table values, and a media entry. For EPUB, they confirmed the container metadata, readable XHTML, expected text and table values, and an image entry. These checks established that Pandoc ran and that Typora passed representative content and resources through the integration.

The acceptance boundary can be summarized as follows:

Layer	Evidence	What it proves
Installation	pandoc --version succeeds	A converter executable can run in a fresh shell
Application binding	Typora records or uses the selected executable	The editor knows which process to launch
Export execution	DOCX and EPUB files are created	Both requested formats completed
Package structure	Required entries and embedded media exist	The outputs are structurally populated
Content check	Unicode text and table values are present	Representative document data survived conversion

Limits and reusable conclusion

This workflow covers Pandoc-backed DOCX and EPUB output on Windows. Executable locations and preference labels can vary, so discovery output should guide configuration. Custom reference documents, EPUB CSS, filters, citations, mathematics, and reader-specific styling need their own test documents.

Pandoc-generated PDF is a separate path because it commonly needs an additional PDF engine. Installing a large TeX distribution is unnecessary when the required scope is limited to DOCX and EPUB.

When an editor exposes an export format through an external converter, test the integration as a process chain. Prove executable discovery, bind the path when needed, export representative content, and inspect the real artifact. That evidence is stronger than either a visible menu item or a success notification on its own.