Markdown Here renders your Markdown in the mail compose box, and reverting throws away your HTML edits

The hotkey is SHIFT+ALT+M, and it only fires in the rich editor

The whole interaction is one toggle. After installing, you log into Gmail, Hotmail or Yahoo and start a new email, or start a new message in Thunderbird. You compose in Markdown, then you right-click in the compose box and choose Markdown Toggle, or click the button the extension puts on your toolbar, or press SHIFT+ALT+M. What appears is the same text rendered to rich HTML.

One prerequisite decides whether any of that works: the rich editor has to be on. In Gmail you click the Rich formatting link if it is visible, and in Thunderbird you enable Compose messages in HTML format under Account Settings in the Composition & Addressing pane. Skip that and there is no rich body to render into, so the toggle has nothing to convert and the failure looks like the extension ignoring you.

Fenced code blocks get syntax highlighting as a side effect, by naming the language in the fence. The example the README gives is short enough to memorise:

alert('Hello syntax highlighting.');

The original problem this solves is stated plainly in the file: writing email with code in it is tedious, so the author used to write Markdown in the GitHub in-browser editor and copy the preview into the message. The extension removes that round trip, at the cost of putting a script inside the mail page.

It injects a menu item into somebody else's compose box

Markdown Here is a content script that runs on the webmail page and adds a context-menu entry and a toolbar button to a compose widget it does not own. The tell is the first usage step: reload your webmail page, or restart the browser, after installing. A page that was already open does not get the new menu item, because the script attaches when the document loads.

The same mechanism explains the compatibility shape. The named surfaces are Gmail, Hotmail and Yahoo in a browser, Thunderbird for desktop mail, and Google Groups posts; a footnote extends the list to Blogger posts, Evernote notes and Wordpress posts, with TeX formulae handled as well. The table of contents also promises a Compatibility section and a Troubleshooting section, which is where a maintainer would put the details of which client versions are known to work.

What that design cannot do is survive a redesign on the other side. The extension binds to markup owned by Google, Microsoft, Yahoo or Mozilla, and compatibility with a given client is a fact about two projects that move independently.

Reverting to Markdown discards every edit you made to the HTML

The toggle is reversible: right-click anywhere inside the rendered block and choose Markdown Toggle again, and the compose body changes back to the Markdown you wrote. The catch is stated in one line, and it is the kind of line that costs somebody an afternoon.

Any changes you made to the pretty HTML are lost when you revert. The extension does not merge the two versions, it swaps between them. So the sequence that hurts is easy to reach: convert, then fix a line break or a link by hand in the rendered view, then right-click to check what the Markdown underneath actually says. The hand edits are gone.

In Gmail there is a second route, the browser Undo command, CTRL+Z on Windows and CMD+Z on macOS, or the Edit menu. The README warns that you might also lose the last few characters you entered, so the escape hatch has its own cost. In Thunderbird the compose window is a separate document, and nothing in the file describes a per-message undo for the conversion, so the safe habit is to treat the rendered HTML as read only.

Hotmail and Yahoo have no blockquote, so select before you toggle

Replies are where the same action behaves differently depending on the provider. In Gmail, Thunderbird and Google Groups you can use Markdown Toggle on a reply as normal: write your reply at the top, the bottom or inline, convert, and the original message is left alone. The mechanism is that existing blockquote blocks are left intact.

Hotmail and Yahoo do not put the original message in a blockquote, and the same whole-message toggle will convert the quoted history along with your text. The fix is the selection route, which is available in every client: select what you wrote, right-click the selection, choose Markdown Toggle, and only that part is rendered. To undo a selected conversion, put the cursor anywhere inside the converted block and toggle again.

So two routes exist with different failure modes, and the provider decides which is safe by default. Select your own text before toggling in Hotmail and Yahoo, and treat the whole-message toggle elsewhere as a privilege that depends on the client wrapping quoted text in a blockquote.

The Makefile builds the bundles, and Chrome loads them unpacked from src/

For a contributor, the build side is a Makefile and nothing more elaborate. It declares DIST_DIR = dist and UTILS_DIR = utils, makes the build target depend on the clean target, and runs node "build.js" from the utils directory; clean removes the dist directory. The two invocations that matter are:

make build
make all

`all` is clean followed by build, so it is the one to run from a dirty tree. Where those bundles end up matters for the developer install: the manual Chrome path in the README asks you to clone the repository, open the Extensions settings, tick the Developer Mode checkbox, click Load unpacked extension, and navigate to the cloned repo and then the src directory, then reload your webmail page. Firefox and Thunderbird developers are sent to the MDN article called Your first WebExtension instead.

One gap is worth knowing before you start. The repository root has no package.json and no lockfile, so nothing the project publishes says how the dependencies of utils/build.js get installed. There is an .eslintrc.json, a test/ directory, a contributors/ directory and store-assets/, and you bring your own JavaScript toolchain.

Mozilla review holds a fix for a month, and Opera needs version 16

The Firefox and Thunderbird route goes through the Mozilla Add-ons site, either from the listing or from Tools then Add-ons and a search for Markdown Here, and the README asks you to restart Firefox or Thunderbird afterwards. The same section carries the operational warning: it takes up to a month for Mozilla to approve changes to the extension, so features and fixes shown in the repository lag what you can install, and the file points at the list of versions page if you want the newest build before it has been reviewed.

That is a real fork in the road for anyone depending on a fix. A reviewed build can be a month behind the repository, and the alternative is a build nobody has reviewed.

Opera is narrower: the extension only works with Opera 16 and above, meaning the Chromium-based versions, and it installs from the Opera add-ons store. The last line of that section tells you to reload your webmail or restart Chrome, which is a leftover from the Chrome instructions above it. Small, but it is the kind of detail that tells you the section was copied rather than tested on Opera.

Nothing in the repository has changed since the push on 2025-08-22

Licensing and privacy are the tidiest part. The project is MIT licensed, with a LICENSE file at the root plus CLA-entity.md and CLA-individual.md for contributor terms and a PRIVACY.md next to them. CHANGES.md sits there too, so the release history has a written trail.

The activity record is the part to plan around. The recent tags are v2.16.0 from 2025-07-10, v2.15.1 from 2025-06-30 and v2.15.0 from 2025-06-24, and the last push to the master branch was on 2025-08-22. So the newest tagged build is more than a year old, and the work that followed it was never tagged.

For an extension that rewrites your mail composer, the consequence is not missing features, it is that you own the compatibility check. Read the permissions your provider shows at install time, because if a webmail client changes its compose markup after 2025-08-22, this repository is not where that gets fixed.

Editorial conclusion

Use it if you send code, patches or structured text by email every week and you are willing to reload the compose page when it misbehaves. Do not use it as a Markdown editor, since it has no editing surface of its own, and do not hand it a message you have already hand-formatted in HTML. Before you install, check the extension permissions your mail provider shows you, and note that the newest tagged build is v2.16.0 from 2025-07-10 with the last push on 2025-08-22, so nothing in this repository will fix a webmail change that lands after that date.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes