MO to PO Converter
Decompile a binary GNU gettext .mo file back into readable .po translation source. Runs entirely in your browser — no upload.
Input
Pick a .mo file. It's decoded locally — never uploaded.
Output
More ways to use this tool
REST API
curl -X POST https://api.iotools.cloud/v1/tool/mo-to-po \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"file": "data:application/octet-stream;base64,3hIElQAAAAA…"
}'Swap in your own key from your account. The tool's fields are the body — no wrapper.
Ask an AI agent
Use the IOTools `mo-to-po` tool (MO to PO Converter) on this input:
YOUR_INPUT_HEREPaste this at any agent connected to the IOTools MCP server, then add your input.
Embed widget
<iframe
src="https://iotools.cloud/embed/mo-to-po/"
width="100%" height="520" frameborder="0" scrolling="no" loading="lazy"
title="MO to PO Converter — iotools.cloud"
sandbox="allow-scripts allow-forms allow-same-origin allow-downloads allow-popups allow-popups-to-escape-sandbox"
allow="clipboard-write"
style="width:100%;border:1px solid #e5e7eb;border-radius:12px;overflow:hidden"></iframe>
<script src="https://iotools.cloud/embed.js" async></script>Drop this into your own page — free, no key required, just a link back.
| Cost per API/MCP call | From 5 credits |
|---|
Also available with
Guides
A .mo (Machine Object) file is the compiled binary form of a GNU gettext translation catalog — the format PHP, Python, glibc, and WordPress actually load at runtime. It's fast to read in code but useless to edit by hand. This converter decompiles a .mo file back into plain-text .po source, so you can read or edit the translations without installing gettext or a PHP/Python toolchain.
How to use it
Upload your .mo file — the file is decoded entirely in your browser and never leaves it. The decompiled .po source appears instantly; copy it or download it as messages.po.
What it supports
- Both byte orders — a
.mofile can be little-endian or big-endian depending on the machine that compiled it. Both are detected automatically from the file's magic number, same asmsgunfmtand every other real gettext reader. - Plural forms — gettext's NUL-joined binary plural encoding is split back out into
msgid_pluraland indexedmsgstr[0],msgstr[1], …. - Message contexts — a compiled
msgctxtkey is split back out into its ownmsgctxtline, matching whatpgettext()/_x()compiled in. - Multi-line output — a long translated string (most visibly the catalog header, with its
Content-Type/Plural-Formsmetadata) is wrapped across quoted continuation lines the waymsgunfmtformats it, rather than one unreadably long line.
What's lost in compilation
A .mo file carries no fuzzy markers or comments — msgfmt strips them when compiling, and translator comments, source-file references, and #, fuzzy flags are simply gone from the binary. Decompiling can't recover what was never compiled in, so the output is clean msgid/msgstr pairs only.
Privacy
Everything happens client-side — reading the binary .mo container and rendering it as .po text both run in your browser. Nothing is uploaded to a server.
The output doesn't look identical to my original .po file
That's expected. .mo compilation is lossy by design (see above) — fuzzy flags, comments, and source references don't survive the round trip, and entries come back sorted the way msgfmt stored them rather than in your original file's order.
I need to go the other way, from editable .po to a compiled .mo
Use the PO to MO Converter — the exact inverse of this tool, also entirely client-side.
For editing other structured translation/config formats, see the Java Properties File Formatter.