TinyMCE export: choose the supported PDF or Word conversion path

For a current TinyMCE integration, use the dedicated Export to PDF or Export to Word plugin for those file formats. Both collect editor HTML and styles and send them to a configured server-side converter. Tiny's current documentation identifies them as paid add-ons to a TinyMCE subscription. Reading getContent() alone returns HTML; renaming that string to .pdf or .docx does not convert it. Export to PDF, Export to Word.

A fictional workshop coordinator maintains a printable equipment briefing in TinyMCE. Volunteers need a fixed PDF, while a partner organization needs an editable Word copy. The coordinator must choose the format deliberately and inspect the generated files, especially where a table or diagram crosses a page boundary.

Identify which export integration the application uses

Check the installed TinyMCE version and the configured plugin names before copying an older example. The legacy export plugin documentation now labels that plugin deprecated and says it will be removed in TinyMCE 9.0. That notice is a migration condition, not evidence that a specific installed application's export has already stopped working. Legacy Export documentation

The dedicated current controls use these plugin and toolbar identifiers:

Intended file Plugin Toolbar control
PDF exportpdf exportpdf
Word document exportword exportword

Adding a toolbar name alone is insufficient. The matching plugin, subscription entitlement, converter service, and authentication configuration must be available. Follow the official setup for the deployment actually used by the application, whether Tiny Cloud or a self-hosted converter.

Keep the converter configuration with the matching version

The PDF documentation describes an API transition: TinyMCE 8.4.0 and newer support its v2 API and automatic conversion of older flat export options. Existing flat options and newer nested v2 options have different configuration shapes. Confirm the editor and converter versions together before migrating a working integration.

Use the documented server-backed authentication route for the chosen service. Keep signing secrets on the server. Copying an example token into client source is not a durable production authentication plan, and a browser toolbar cannot supply a missing converter endpoint.

For a PDF failure, inspect the actual conversion request and response. Distinguish plugin loading, authentication, service compatibility, and content conversion errors. A successful HTML save establishes none of those export conditions.

Include the content styles the file needs

The current conversion plugins combine editor HTML with content styles and configured export styles. Styles used only around the editor's application shell do not automatically describe the exported briefing.

Use a short original acceptance document with these visible requirements:

  • A heading, “Recorder checkout briefing.”
  • A two-column table identifying the recorder and its supplied battery.
  • A diagram followed immediately by the instruction “Check the battery door before leaving.”

Decide the required page size and margins in the actual export configuration. Export that same document to each required format. Inspect table borders, diagram proportions, and the instruction's position. An on-screen editor can be continuous while a PDF is paginated, so matching the browser's scroll view is not the acceptance criterion.

For Word, open the resulting .docx in the receiving organization's identified reader. Check the table and the editable text there. The official Word documentation lists compatibility limitations, including possible issues with older Word versions and unsupported enhanced media embeds. A playable web embed should not be promised as working media in the Word file.

Keep export and saving as separate actions

The plugins collect the current editor content for conversion. That does not establish that the corresponding source record was saved to the application's database. If the briefing needs an approved revision, save and identify that revision through the existing document service, then make the intended export from it.

The TinyMCE content capture guide covers reading the current editor and synchronizing a backing textarea. It solves the source capture step, while PDF and Word export add conversion and file review.

Name each generated file so its briefing revision and format are clear. Reopen the actual downloaded file, read the battery-door instruction, and check the final page. Send the PDF or Word file requested by the recipient, with the editable TinyMCE record retained in its normal source system.

Keep reading