VSCodeでMarkdownファイルをデフォルトでプレビューモードで開くように変更する方法 VSCodeでMarkdownファイルをデフォルトでプレビューモードで開くように変更する方法

Visual Studio Code opens Markdown files in its text editor by default, showing the raw syntax rather than the rendered document. For developers who increasingly work alongside AI coding agents, that default can feel backwards: these tools tend to generate a steady stream of Markdown artifacts—README files, design notes, task breakdowns, and architecture summaries—and the day-to-day reality is that you read these documents far more often than you edit them. Configuring VSCode to open Markdown in preview mode by default is a small change that can meaningfully smooth a reading-heavy workflow.

Out of the box, VSCode already includes a capable Markdown renderer. You can trigger it manually with the command "Markdown: Open Preview" (Ctrl+Shift+V, or Cmd+Shift+V on macOS) to replace the current editor with a rendered view, or "Markdown: Open Preview to the Side" (Ctrl+K V) to show source and preview together. These shortcuts are useful, but they require a deliberate action every time you open a file, which is exactly the friction the default-preview approach aims to remove.

The mechanism that makes this possible is the workbench.editorAssociations setting, which lets you map file patterns to a specific editor. By associating the Markdown glob with the built-in preview editor, VSCode renders the document immediately on open instead of dropping you into the source view. A typical configuration in settings.json sets the key "workbench.editorAssociations" to an object that maps "*.md" to the view type "vscode.markdown.preview.editor". After saving, opening a .md file from the Explorer should present the rendered output rather than the raw text.

Because this is a standard setting, you can apply it at different scopes. Placing it in your user settings affects every project, while putting it in a workspace's .vscode/settings.json limits the behavior to that repository—helpful if you only want preview-by-default for documentation-heavy projects. It is worth confirming the exact view-type identifier against your installed version, since built-in editor identifiers can change between releases, and the precise behavior may differ if you also have third-party Markdown extensions registered.

There is a trade-off to keep in mind. When preview becomes the default, editing requires an extra step: you reopen the file in the text editor through the "Reopen Editor With…" command, or toggle back to source. For people who genuinely write more Markdown than they read, the original default is probably better. The preview-first setup is best suited to those who treat Markdown primarily as output to be consumed.

This adjustment fits into a broader shift in how documentation is produced and consumed. As AI assistants such as GitHub Copilot, Cursor, and various agentic tools have become common, much of a project's prose is now machine-drafted in Markdown and committed alongside code. The format's plain-text nature makes it easy for these tools to generate and for version control to diff, but it also means the rendered experience—headings, tables, code blocks, and links—matters more to the reader than the surrounding syntax.

For users who want more than the built-in renderer offers, the ecosystem provides alternatives. Extensions like Markdown All in One add shortcuts, table formatting, and table-of-contents generation, while Markdown Preview Enhanced supports diagrams, math, and richer export options. Some teams pair these with dedicated WYSIWYG-style Markdown editor extensions that blend reading and editing in a single surface. None of these are required for the preview-by-default behavior, but they illustrate how flexible VSCode's editor model has become.

It is also worth noting that this setting changes only the visual entry point, not the underlying file. The Markdown source is untouched, so collaborators who prefer the source view, command-line tools, and Git all continue to see the same content. That separation between how a file is stored and how it is presented is part of what makes the editor association approach low-risk to try and easy to revert.

Ultimately, the change described here is less about a hidden feature and more