Import Word Documents into WordPress as Real Blocks, Not One Classic Block

You import a Word document into WordPress. The text is all there, the headings look right, the pictures came through. Then you click into the post and the whole thing is one block: a grey Classic block holding the entire document.

You can't drag a paragraph somewhere else. You can't insert an image between two sections without fighting the old toolbar. List View shows a single row.

That is not a problem with your document. It is about the format the content was saved in, and it is fixable at import time.

Why it ends up as one Classic block

The block editor does not decide where blocks are by looking at your text. It reads markers saved in the post. A block-editor post, stored in the database, looks like this:

<!-- wp:heading -->
<h2 class="wp-block-heading">Results</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Sales rose in every region.</p>
<!-- /wp:paragraph -->

Those HTML comments are the blocks. Readers never see them, but the editor uses them to know that this is a Heading block, that is a Paragraph block, and where each one starts and stops.

Most importers save plain HTML: the <h2> and the <p> with no comments around them. Faced with that, WordPress has no safe way to guess the structure, so it does the only lossless thing: one Classic block, everything inside.

The same thing happens to any post written in the old Classic editor and opened in the block editor later. If you have ever pasted Word into WordPress and seen it, there is more on that in why you should stop copy-pasting Word docs into WordPress.

The manual fix, and why it does not scale

Select the Classic block, open its toolbar, and choose Convert to blocks. WordPress splits the HTML into blocks as best it can.

For one post that is fine. But it is a step you have to remember on every post. WordPress also guesses at tables and images, so they need checking afterwards. And on a bulk import of 100 documents it means opening 100 posts and clicking the same menu 100 times.

The better place to fix it is the import itself.

What a block-aware import looks like

DocxToWP reads the .docx file directly and, when you publish, saves the result with the block markers already in place. Each part of your document becomes the block you would have picked yourself:

Markdown files get the same treatment, plus Code blocks for fenced code, Quote blocks for > quotes and a Separator for ---. The Markdown import guide covers that side.

Anything without a block of its own goes into a Custom HTML block, unchanged. Nothing is dropped.

Tables use your theme's styling

Word tables carry their own borders and cell padding. As a Table block, they pick up your theme's table style instead, so they match every other table on your site. Colours and highlights on words inside the cells are kept.

The preview stays simple

The block markers are added when you publish, not before. The preview screen still shows your document as ordinary editable text, so you can fix a heading or a typo without wading through block comments.

The Content Format setting

Whether you get blocks is controlled by one setting:

• Free plugin (DocxToPost): Settings → Content Format
• DocxToWP Pro: Settings → Post Defaults → Content Format

It has three options:

Match the editor (recommended, the default). For each post type, it checks which editor WordPress uses. Block editor: you get blocks. Classic Editor: you get plain HTML, which is what the classic editor expects. A site with the Classic Editor plugin needs no changes.

Always block editor. Always save blocks, whatever WordPress reports. Useful if a plugin hides which editor a post type really uses.

Always classic HTML. Always save one piece of HTML, the old behaviour. Pick this if your workflow depends on it, for example a theme or tool that reads post_content as plain HTML.

Where it works

The free DocxToPost plugin on WordPress.org has saved real blocks since version 1.1.0.

DocxToWP Pro does from version 1.4.5, released on 2 November 2026. It covers every route in, the same way:

• single Word uploads and Markdown files
• Google Docs, by link or picked from your Drive
• Bulk Import, including re-imports that update an existing post

One exception in Pro: a document imported with its Word layout (columns, panels and positioned shapes) stays as HTML. That layout is a single positioned unit, and splitting it into blocks would break it apart.

If you build posts in Elementor: Elementor opens any existing post content as one Text Editor widget, blocks or not. That is how Elementor works. The block output is for the WordPress block editor.

Try it on your own document

Take a real document with a few headings, a list, a table and a picture. Import it, publish it as a draft, and open List View (Shift + Alt + O). Every part should be its own row, ready to edit.

The full list of what changed in each version is on the changelog. Bulk imports, Google Drive and scheduled publishing are in DocxToWP Pro.