Opening a format that still matters
HWP is not an obscure legacy curiosity in South Korea. Government agencies, schools, courts, and companies still exchange documents in the format, yet most web and cross-platform software cannot do much with them. rhwp attacks that gap with a Rust parser, document model, layout engine, serializers, and several rendering backends compiled for native use and WebAssembly.
The project's main documentation is Korean. A detailed English README covers the public feature set, installation, architecture, and examples, but the project says its roadmap source of truth remains Korean. Some deeper material, including the MCP integration guide, is also Korean. That is workable for an English-speaking evaluator, but it will matter when a team has to debug an unfamiliar layout rule or contribute a fix.
rhwp handles HWP 5.0, XML-based HWPX, and a constrained subset of HML. It parses paragraphs, tables, images, equations, charts, headers, footers, master pages, and footnotes. Output can go to SVG, PNG, PDF, browser canvases, or back into supported document formats. A web editor adds text and table operations, while compatibility methods imitate 30 actions from Hancom's hwpctl interface.
More than a document viewer
There are several credible ways to use the project. Someone who only needs to inspect a file can open the hosted demo or install a Chrome, Edge, Firefox, or VS Code extension. A web product can embed the full editor through @rhwp/editor, or call the lower-level @rhwp/core WebAssembly API and render individual pages as SVG. Native release archives expose inspection and export commands without requiring a Rust build.
The built-in MCP server is particularly practical for Korean document automation. Claude Code or another MCP host can ask for document metadata, search for text, locate cells, fill named fields, and convert files. Large documents can remain open in a session so repeated queries do not reparse the source. This is a better interface for an agent than asking it to infer a binary format from extracted garbage. It also keeps the document processing local to the user's executable.
The internals show unusual care for preservation. HML support is intentionally limited to structures verified against a real corpus. A preflight check permits saving an HML-origin document only when unsupported pieces will not be lost, and blocks loss-prone cases such as pictures or external resources. Direct PDF similarly rejects certain effects and recommends the SVG compatibility route rather than pretending every visual feature survived. Those failure modes are inconvenient in the right way.
Rendering breadth brings rendering risk
The README describes four related rendering routes: legacy and layered SVG, browser Canvas2D, CanvasKit, and native Skia for PNG or direct PDF. A shared paint representation tries to keep their ordering consistent. Canvas2D remains the compatibility default for Studio, browser extensions, embeds, and VS Code, while an opt-in automatic mode selects CanvasKit only after document and font checks pass.
This engineering is substantial, but it should not be confused with finished fidelity. Open issue #4024 documents paragraphs placed beyond a page boundary and therefore missing visually even though text extraction still sees them. Issue #4770 describes a change that spread nine foreground images across nine pages and increased a real document from 246 to 260 pages, while the Hancom reference had 235. These are not cosmetic differences for a filing, a printed form, or a page-specific citation.
Save fidelity also needs testing. Issue #4599 tracks 242 HWPX files with in-page layout drift after a save ladder, following a corpus sweep of thousands of documents. Issue #4741 shows another practical failure: a Korean font installed on Windows was omitted from the local-font inventory and replaced with a monospaced fallback in the Canvas2D path. Font metrics then change line breaks, table heights, and pagination.
The project's public issues are unusually specific, with reproduction data, bisects, corpus identifiers, measurements, and proposed acceptance criteria. That increases confidence in the maintenance process, but it also gives buyers a clear warning: format coverage and exact page composition are different achievements.
Setup ranges from trivial to specialist
The quickest trial takes minutes. Use the demo, add an extension, install one npm package, or download a release archive and run rhwp capabilities. Releases provide Linux x86_64, macOS Intel and Apple Silicon, and Windows x86_64 binaries with SHA-256 checksums. An MCP setup then needs only the executable on PATH and a short server configuration.
Building the whole system is more demanding. The repository pins Rust 1.93.1, uses Docker to standardize the WASM toolchain, and needs Node.js 18 or newer for the editor. Native Skia features, several output backends, browser behavior, open fonts, and visual comparisons all expand the test matrix. The README cites more than 3,400 Rust tests plus frontend, end-to-end, and visual-regression checks. Contributors should start with the onboarding guide rather than treating cargo build as the whole environment.
Release v0.8.4, published August 12, 2026, is also revealing. It removed PyPI, Node binding, package-manager, installer, container, and operating-system package channels that had been unintentionally activated in v0.8.3, while retaining npm packages, native release binaries, editor extensions, and browser extensions. The narrower policy is responsible, though it shows that distribution is still settling.
Health and the buying decision
The last push was August 14, 2026. GitHub reported 189 open issues and three open pull requests, and recent issue threads were receiving same-day investigation and fixes. The queue is large because the project tracks fine-grained renderer experiments and corpus findings, not simply user bug reports. The repository is MIT licensed and the README credits more than 40 outside contributors plus two collaborators.
rhwp is easy to recommend for reading, extraction, search, form filling, and reviewed web previews where no good open option existed. Its honest loss barriers and deep test work are real strengths. For authoritative printing or invisible round-trip editing, compare outputs against Hancom with representative documents and pin a tested release. This project is solving the hard problem in public, but its own evidence says the hard problem is not finished.