Mcat: A Rust terminal viewer for documents, images, video, and Markdown
Terminal image, video, PDF, and Markdown viewer
At a glance
- What is it?
- Mcat is a command-line viewer and converter built in Rust for people who want to inspect common files from a terminal instead of opening separate applications. It supports local paths, URLs, stdin, multiple output formats, interactive navigation, and optional Chromium and FFmpeg dependencies.
- Who is it for?
- Mcat fits developers who want a single terminal-based path for previewing and converting mixed document types, especially when working over SSH or piping files into another command. It is a poor fit for workflows that require an always-available graphical office suite or that cannot install Chromium or FFmpeg.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Why Mcat exists for terminal-first workflows
Mcat addresses a specific interruption in terminal-centered work. Without a specialized viewer, checking a PDF, image, presentation, archive, or Markdown file often means leaving the shell for a separate application. Mcat keeps the interaction at the command line and accepts several kinds of input: a local file, a URL, or bytes supplied through stdin. That makes it relevant to developers, system administrators, and users who inspect files over SSH or work inside constrained terminal environments.
The project is not limited to previewing images. Its documented scope includes images, video, Markdown, PDF, and Office documents, while the examples also include HTML, Typst, source files, ZIP archives, CSV, and other inputs. The README presents Mcat as a viewer and converter rather than only a thumbnail utility. The same input can be displayed in the terminal, written as Markdown or HTML, rendered as a PNG image, or sent to an interactive viewer.
This combination has a clear operational appeal. A file can be inspected without naming a dedicated desktop program, and output can be redirected into another tool. The repository topics also identify the terminal graphics context, including kitty, iTerm, and sixel-related terminology. The README does not claim universal graphics support across every terminal, so terminal compatibility remains something to verify rather than assume.
Mcat's input and conversion pipeline
Mcat uses an explicit conversion pipeline. It infers each input's type automatically, then continues processing until it reaches the requested output format. The documented example is `mcat file.docx file.pdf -o inline`: both documents become one Markdown file, the Markdown becomes HTML, the HTML becomes an image, and the image is printed as inline terminal graphics. This sequence explains why the project can use one interface for formats that normally require different viewers.
The output selection changes the pipeline stage. Markdown is selected with `-o md` or when standard output is not a terminal, such as when the output is piped. The Markdown Viewer adds ANSI formatting and is the default for files that are not video or images. `-o html` requests HTML for non-image and non-video files. `-o image` produces a PNG, while `-o inline` and `-i` print content as an image in the terminal. `-o interactive` and `-I` launch an interactive image view with zoom and pan controls.
The project can also begin partway through the pipeline. The README shows `mcat file.html -o image > image.png`, which starts from HTML and writes a PNG without entering interactive mode. Multiple inputs can be combined, which is useful for concatenating documents into one rendered result. The repository workspace separates the core command, `markdownify`, and `rasteroid`, indicating that conversion responsibilities are organized into multiple Rust crates. The repository files shown here do not document a separate plugin API or a public pipeline extension interface.
Installing Mcat and running a first conversion
The README provides source installation, prebuilt releases, Homebrew, Arch User Repository, Nix, and Scoop paths. The following source installation command installs the published `mcat` package through Cargo:
cargo install mcatUsers who want the repository version can clone it and install the core crate from the workspace path:
git clone https://github.com/Skardyy/mcat
cd mcat
cargo install --path ./crates/coreThe prebuilt route directs users to the latest GitHub release instructions. For Homebrew, the documented command is:
brew install mcatAfter installation, a first real use can render a Markdown file directly in the terminal. The command below displays `README.md` as inline terminal graphics:
mcat README.md -iFor conversion rather than display, the project documents Markdown and HTML output through standard output redirection:
mcat archive.zip > README.md
mcat f1.rs f2.rs -o html > index.html
mcat index.html -o image > page.pngThese commands show Mcat's redirect-friendly behavior. The first example is intended to produce Markdown from an archive, the second combines Rust files and writes HTML, and the third renders HTML to a PNG file. The README does not state the exact command used to inspect supported formats beyond linking to `support.md`, so that table is the right place to check before assuming a particular extension will work.
Interactive viewing, inline graphics, and optional dependencies
For visual inspection, Mcat distinguishes terminal display from an interactive viewer. `mcat massive_image.png -I` opens an interactive view where the user can zoom and pan. The same mode can accept rendered PDFs or several files, as shown by `mcat document.pdf -I` and `mcat img.png README.md -I`. This is a different operation from `-i`: inline mode prints an image directly into terminal output, while interactive mode changes the viewing behavior for navigation.
Image and video support may depend on external software. The README identifies Chromium as the optional dependency for rendering HTML, Markdown, and text into an image. It can use an installed Chrome, Edge, or Chromium, and it says Microsoft Edge is available by default on most Windows machines. Mcat can attempt to install Chromium itself with the documented command:
mcat --fetch-chromiumVideo support uses FFmpeg. Mcat can use an FFmpeg installation already present on the system, or it can install it with:
mcat --fetch-ffmpegThe README says Mcat continues working without these optional dependencies, but the relevant feature may then be unavailable. In particular, treating all image, video, and document rendering as identical would be inaccurate. The feature matrix in `support.md` is the documented authority for file-type and feature combinations. Terminal graphics support also depends on the terminal and image protocol. The repository documentation names iTerm, kitty, and sixel topics, but it does not provide a complete terminal compatibility matrix.
Where Mcat is constrained compared with dedicated viewers
Mcat is the wrong tool when the requirement is a complete graphical office application rather than terminal inspection or conversion. Its documented input and output modes focus on terminal rendering, Markdown, HTML, PNG, and interactive image navigation. The examples do not document editing a DOCX or PPTX, annotating a PDF, selecting office text, or preserving an editable presentation structure. It should therefore be evaluated as a renderer and converter, not as a full replacement for an office suite.
There is another practical constraint around dependencies and output environments. Converting a URL or stdin payload can involve network access, temporary files, browser rendering, or FFmpeg processing, depending on the input and requested output. The README does not document timeout policy, cache behavior, resource limits, or how failed external processes are surfaced. Those omissions matter in automation, especially when Mcat is used inside a script or service.
A direct alternative is to use separate format-specific tools and retain the output in a conventional file. For example, a browser or PDF application can handle native documents, while a dedicated image editor can provide editing and detailed metadata inspection. The actual difference is scope: those tools own their formats and expose richer editing controls, whereas Mcat combines local files, URLs, stdin, conversion, and terminal display behind one Rust CLI. Mcat is more convenient when the shell is the common workspace and output needs to stay textual or renderable in a terminal.
Mcat's release activity and maintenance implications
The repository is not archived, and its last push was on 2026-10-14. The recent release list includes v0.6.5 on 2026-08-29, v0.6.4 on 2026-07-30, and v0.6.3 on 2026-07-21. These dates indicate recent release and repository activity, but they do not by themselves establish compatibility with every terminal or guarantee that each format has the same feature coverage.
Mcat is distributed under the MIT license. That is relevant to teams considering redistribution or integration, although license obligations should be checked against the actual project files and intended distribution model. The repository includes a Rust workspace with `crates/core`, `crates/markdownify`, and `crates/rasteroid`, plus a `Cargo.lock`. Users installing through Cargo may receive a packaged version, while users following the source instructions build the core crate from the checked-out workspace.
Upgrade cost is likely to depend on the dependency path. Homebrew, Scoop, AUR, Nix, Cargo, and prebuilt releases are documented installation routes, but the README does not provide a migration guide for configuration, caches, or changes between release versions. Teams that depend on exact rendering output should compare a representative Markdown file, PDF, image, and video after upgrading. The `CHANGELOG.md` file is linked by the README as the release-specific place to inspect for changes.
Editorial conclusion
Mcat fits developers who want a single terminal-based path for previewing and converting mixed document types, especially when working over SSH or piping files into another command. It is a poor fit for workflows that require an always-available graphical office suite or that cannot install Chromium or FFmpeg. Before adopting it, verify support for the exact file types in support.md, test rendering in the target terminal, and check whether interactive and inline modes work with the terminal's graphics protocol.
Frequently asked questions
How do I install Mcat on my system?
Mcat documents installation through Cargo, Homebrew, the Arch User Repository, Nix, Scoop, or a prebuilt release. For a Cargo installation, run `cargo install mcat`.
What file types can Mcat view?
The README identifies images, video, Markdown, PDF, and Office documents as supported areas. Its examples also use HTML, Typst, Rust source files, ZIP archives, CSV, URLs, and stdin, but `support.md` should be checked for exact feature coverage.
Does Mcat need Chromium or FFmpeg?
Chromium is used for rendering HTML, Markdown, and text into images, while FFmpeg is used for video. Mcat can use already installed software or fetch it with `mcat --fetch-chromium` or `mcat --fetch-ffmpeg`.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/skardyy-mcat)Was this useful?