For a new Hatena Blog article, use the platform's Markdown mode first. Convert to Hatena notation only for existing Hatena-notation posts or workflows that require it.
Contents (8)
Hatena Blog is a Japanese blogging platform with several editing modes, including Markdown and its own Hatena notation.
If ChatGPT or Claude already gives you Markdown, the first question is not "how do I convert it to Hatena notation?"
The first question is: do you need to convert it at all?
For a new post, Markdown mode is usually the simplest choice. Conversion is useful when you are adding to an existing Hatena-notation article, keeping an older blog workflow consistent, or relying on Hatena-specific syntax.
| What you are doing | First choice | When conversion is useful |
|---|---|---|
| New article written in Markdown | Hatena Blog's Markdown mode | Usually unnecessary |
| Add to an existing Hatena-notation article | Keep the existing mode | Convert the new Markdown section |
| Blog workflow standardized on Hatena notation | Hatena notation mode | Convert before publishing |
| Mostly visual editing | Visual editor | Usually no Markdown conversion |
| Same source also goes to WordPress or Word | Keep Markdown as the source | Convert only at the destination |
For a new post, prefer Markdown mode
If you already write in Markdown in ChatGPT, Claude, Obsidian, or VS Code, creating the Hatena Blog post in Markdown mode keeps the workflow simple.
That gives you a portable source that can also be reused for WordPress, Word, or other destinations.
Do not convert to Hatena notation just because the final destination is Hatena Blog.
Decide the editing mode before you commit the post
Hatena Blog's editing mode is an important workflow decision.
The platform supports multiple modes, and Hatena's official help states that once an article has been saved as a draft or published, its editing mode cannot be changed.
So if you start a new article in Markdown mode, keep it there. If you are editing an older article created with Hatena notation, the added content needs to fit that mode. Switching modes while composing a new post can also clear the current body, so choose the mode before pasting a long draft.
For that reason, keep the Markdown source outside the editor until you know which mode you are using.
When conversion to Hatena notation is useful
You are extending an existing Hatena-notation article
If an older article is already maintained with Hatena notation, converting only the new section is reasonable.
Your blog has a long-running Hatena-notation workflow
Consistency can matter more than adopting Markdown for a single post.
You rely on Hatena-specific syntax
Hatena notation includes service-specific features and conventions that do not map directly to standard Markdown.
In that case, Markdown can remain the source while Hatena notation becomes the publishing output.
Conversion details that need semantic handling
Do not convert by replacing characters mechanically
Markdown and Hatena notation are both lightweight markup, but similar-looking symbols can represent different document levels.
For example, a blog Markdown source may use:
## Main section
### Subsection
A Hatena-notation article may need the equivalent hierarchy expressed with its own heading syntax.
The goal is not "replace two hashes with two asterisks." The goal is preserve the document hierarchy.
Lists also use different nesting rules
Markdown commonly nests list items with indentation:
- Parent
- Child
- Grandchild
Hatena notation represents nesting differently.
So list conversion needs to preserve the parent-child structure rather than copy the original spacing blindly.
Quotes and tables need semantic conversion too
Markdown quotes use > at the beginning of quoted lines.
Hatena notation has its own range-based quotation syntax.
Markdown tables use a delimiter row:
| Item | Value |
| --- | --- |
| A | B |
Hatena notation uses a different table convention.
Because both formats can use pipe characters, tables can look deceptively similar. The header row and delimiter logic still need proper conversion.
Keep Hatena-specific features out of the source when possible
If you use a Hatena-specific table of contents or service-specific embed syntax, add it during the publishing step instead of making it part of the portable Markdown source.
That keeps the original document reusable.
A simple model is:
ChatGPT / Claude
↓
Markdown source
↓
review
↓
Markdown mode directly
OR
convert to Hatena notation
↓
Hatena Blog preview
Where Yomu fits
Yomu can be used when conversion is actually necessary.
The intended workflow is:
- keep the original article in Markdown
- check heading levels, lists, tables, code, and links
- convert the document structure to Hatena notation
- paste it into an article that uses Hatena-notation mode
- verify the result in Hatena Blog's preview
If your new post already uses Markdown mode, skip this conversion entirely.
Why not ask the AI to convert the notation every time?
For short text, asking ChatGPT or Claude to convert Markdown to Hatena notation can be adequate.
For a long article, though, you then need to verify that the AI changed only the notation.
Check whether it also altered:
- heading text
- URLs
- table cells
- code characters
- list structure
- wording
A deterministic converter is easier to audit when the required transformation follows known rules.
Privacy for unpublished drafts
Markup conversion does not inherently require a server or another AI call.
Yomu performs its core Markdown conversion workflow in the browser, so the document body does not need to be sent to a conversion server just to change notation.
Summary
For new Hatena Blog posts, use Markdown mode when you already have a Markdown source.
Convert to Hatena notation only when the article or the existing blog workflow requires it.
When conversion is necessary, preserve document meaning—heading hierarchy, list nesting, quotes, tables, code, and links—rather than doing simple character replacement.
That keeps Markdown useful as the source of truth while Hatena notation remains a destination-specific output.