mrkeyoor.com_
Sat 15 Aug 16:52 UTC
Webevaluationupdated 15 Aug 2026

convert

Convert to it! is a browser-based file converter that keeps files on your device instead of uploading them to a remote conversion service. It connects many specialist format handlers so it can attempt unusual conversions across images, audio, video, documents, archives, fonts, and other media.

Verdict

Convert to it! is an unusually useful first stop for private, oddball conversions, especially when the alternative is uploading a file to a faceless website. Use it as a convenient workshop, not as an archival pipeline: inspect every result and keep the original. Self-host it if the broad interface is valuable to your group, but choose a format-specific tool when output fidelity matters more than range.

Setup4/5Instant hosted use and easy Compose, with a heavier local build
Docs4/5Clear use, deployment, handler, testing, and contribution guidance
Community3/5Active requests and contributions, but a crowded open queue
Maturity3/5Broad and usable, with no releases and uneven handler reliability

Who it’s for

People who want to convert potentially sensitive files without handing them to an unknown server.
Developers who want a self-hosted, web-based conversion utility for a team or household.
Curious users who need an unusual format pair and accept that the result may be interpretive rather than exact.
Contributors interested in wrapping browser-compatible libraries and WebAssembly tools behind one conversion interface.

Who it’s NOT for

Archivists and production teams that require deterministic, fidelity-checked output: the README promises a best effort and admits the result may not be what the user expected.
Desktop users who mainly need large MKV or Opus conversions: an open report says the Electron app crashes on MKV-to-MP4 and Opus-to-MP3 jobs.
Anyone expecting every named format to work merely because it appears in a menu: an open TurboWarp report shows a handler failing at page load because JSZip is unavailable.
Maintainers seeking a small dependency surface: the project combines many npm packages, WebAssembly binaries, Git submodules, and conversion-specific wrappers.
Teams that require versioned, supported releases: the repository has not published a GitHub release.

Setup reality

Using the hosted site requires only a browser, and the prebuilt Docker route is a short Compose command. Local development is more particular: clone recursively so submodules are present, install Bun, install dependencies, and run Vite. The recommended format cache must first be generated in the browser and copied into cache.json; a local Docker build also installs Chromium to build that cache, so the first image build is intentionally slow. The result is still easier than assembling the underlying converters yourself, but this is a substantial web application, not a tiny static utility.

A converter that treats privacy as the default

Most online file converters ask you to upload a document, wait for a server, and trust an unclear retention policy. Convert to it! takes the more reassuring route: its conversion tools run in the browser. The hosted site can therefore handle a file without sending that file to the project's server, and the same interface can be served from your own machine with Docker.

That privacy model is the best reason to try it. The second is range. Rather than restricting users to image-to-image or video-to-video jobs, the project models formats and handlers as a graph. It can find a route through intermediate representations, which makes strange requests possible. An AVI-to-PDF conversion may not produce a document anyone would deliberately design, but the system will try to find a meaningful path instead of refusing because the source and target belong to different media categories.

The project's own language is refreshingly honest about the consequence: users are almost guaranteed an output, but not necessarily the output they imagined. This is an experimental workshop with a practical interface, not a promise that every path preserves meaning.

Breadth comes from real tools, not one magic parser

The application wraps a large collection of specialist libraries and WebAssembly components. Its dependency list includes FFmpeg for media, ImageMagick for images, SQLite, 7-Zip, Typst, PDF tooling, font and music libraries, and several format-specific packages. Git repositories can also be included as submodules when npm is not an option. Each wrapper declares the formats it accepts and produces, then returns immutable byte buffers through a common handler interface.

This architecture is sensible because file conversion is not one problem. Rendering an SVG, decoding an archive, synthesizing MIDI, and turning a PDF page into an image need different engines. The graph lets those engines cooperate while the interface stays simple: select a file, confirm the detected input, select an output, and press Convert.

There is value for developers too. The README provides a small TypeScript handler example and explains naming, MIME normalization, output filenames, categories, mutation rules, and dependency choices. Contributors are asked to treat a file as the media it represents rather than falling back to a raw byte visualization. That rule keeps additions useful instead of merely making the output menu longer.

Easy to visit, more involved to own

For an ordinary user, setup is nonexistent: open the site and drag in a file. Self-hosting the published image is also reasonable. The supplied Compose file maps a static Nginx container to port 8080 under /convert/. There is no database, account system, storage service, or conversion worker to administer.

Development requires more attention. The repository must be cloned with submodules, then Bun installs a sizable dependency set and Vite starts the app. Generating the supported-format list can be slow on first load. The recommended optimization is to wait for the browser to build the list, call a console function, and save its JSON output as the cache. A self-built Docker image automates cache generation, but installs Chromium and Puppeteer during the build, so the README warns that the first build will be slow.

The production container is pleasantly boring after that build: Nginx serves the generated files. Still, operators should expect a large browser download and should test their important formats on the browsers and hardware they actually support. Running locally removes the upload risk, but it does not remove CPU, memory, or browser compatibility limits.

Best effort has visible rough edges

A universal menu can suggest more certainty than the handlers deserve. The open issue queue supplies useful warnings. One report says the Electron build crashes when converting MKV to MP4 or Opus to MP3, even though PNG to PDF worked. Another says the TurboWarp handler throws a JSZip-related error as soon as the page loads. A request to store successful paths in a database also highlights a core usability question: when many routes exist, users may want to reuse one known-good sequence rather than let the graph choose again.

Testing exists at graph, common-format, smoke, and selected handler levels, but the README explicitly says not every handler needs a dedicated unit test. That is understandable for a volunteer project with a huge format surface, yet it shifts verification to the user. A conversion completing is not proof that metadata, timing, layout, color, embedded assets, or naming survived correctly. Keep originals, compare outputs, and use a dedicated converter for repeatable production work.

The issue policy is another signal about scope. Simple requests to add a format are rejected unless the reporter researches the medium, expected behavior, browser implementations, and compatible licensing. That boundary is necessary when thousands of possible formats can generate endless requests, but it also means niche support depends on contributors arriving with unusually complete homework.

Health and the decision

The last repository push was July 7, 2026. Issues and pull requests continued to receive activity through August 14, while the repository reported 152 open issues and PRs. Recent merged work included better error handling, format declarations, archive support, and traversal fixes. There is clear participation, but the queue is large and GitHub lists no published release, so users have no tagged stable checkpoint or release notes to anchor a deployment.

Convert to it! succeeds as a private first attempt and as a playful bridge between format families. It is particularly attractive for one-off files that you do not want to upload. It is less convincing as an unattended service where a technically valid but semantically poor result could pass unnoticed. Try the hosted version, validate a set of representative files, and self-host only after those paths prove useful. For critical PDF, image, or media pipelines, a narrower tool with explicit controls remains the safer purchase decision.

Alternatives

ProjectWhat it isPick it when
File ConverterA Windows shell extension for common audio, video, image, and document conversions.pick this instead when you want right-click conversion on Windows and prefer a narrower desktop workflow.
Stirling PDFA self-hosted web suite focused on PDF conversion, editing, OCR, and document operations.pick this instead when PDF work is the main job and you need deeper document-specific controls.
ffmpeg.wasmA WebAssembly port of FFmpeg for building private in-browser audio and video workflows.pick this instead when you are building a media application and want direct control over FFmpeg commands.

What people are saying

  1. [github-trending] p2r3/convert

Sources

  1. Convert to it! repository
  2. Convert to it! README
  3. Convert to it! package manifest
  4. Docker deployment files
  5. Electron conversion crash report
  6. TurboWarp JSZip error report
  7. Conversion path database proposal