kekingcn/kkFileView

Adopt it when your application must render user-uploaded documents inside a browser tab and you are willing to run a Java conversion service beside your app. Skip it if you only need PDFs, or if the deployment image must stay tiny and passive.

The problem

Today a user uploads a .docx, .dwg, or .zip and the web app either forces a download or asks them to install desklop software. The workflow you want is: upload, click preview, see the content in the browser. kkFileView inserts a server that receives a file URL or uploaded file, converts it, and returns a page the browser can render. The result is a preview link users open in place of downloading the original.

What's different

The mechanism is a Spring Boot service that wraps LibreOffice/OpenOffice (Jodconverter) and other converters, with Redis optional. Office documents are converted and served as PDF or images, and the project exposes a REST API plus an abstract preview interface for adding formats. The README also lists front-end parsing paths for PDF, ODF, CSV, xlsx, 3D models, and converters for CAD to SVG/TIF, plus archive browsing and encrypted-file preview. That breadth is the practical benefit: one service covers many file types instead of each team wiring a viewer per format.

The trade-off is a Java sidecar that installs and drives OpenOffice/LibreOffice, so conversion timeouts, memory and disk usage become your operational concern. Recent notes show upstream taking this seriously: untrusted HTML previews are sandboxed in an opaque-origin iframe with embedded JavaScript disabled by default, and several SSRF, path-traversal and demo-endpoint issues have been closed in changelog entries project changelog. Those are author-reported fixes, not an independent audit. The 3.0-era release also requires JDK 21, changes the default Office preview to PDF mode, and redefines how trust.host matching works, so existing deployments must revisit configuration after upgrade.

Who should try it

Good fit: an internal OA, document management, or intranet portal where staff open contracts, spreadsheets, drawings, and archives in the browser, and the team already runs JVM services. Poor fit: a static site or serverless app that only shares PDFs, since every extra converter and runtime daemon is overhead. A documented Docker image, including ARM64, changes the audience for teams that prefer containers over installing LibreOffice by hand setup details. Check the hosted demo before committing; it is the quickest way to judge whether the rendering quality meets your documents demo site.

Requirements and limitations

JDK 21 or newer is mandatory in the current line. On Linux, the README says Office/LibreOffice is installed automatically; on macOS it must be installed manually, and Windows bundles it. Redis is optional and unnecessary by default, so read the configuration before adding it. The project's license is not declared in the repository metadata, which matters if you plan to redistribute or embed it in a commercial product; confirm terms with the maintainers rather than assuming an OSI license.

Ongoing upkeep is the bigger cost. Conversions depend on an external office suite, timeouts and thread pools are configurable, and the README says converted source files are deleted by default to save disk space. The trust-host and high-risk upload settings govern what the service will fetch or accept, and the security history shows these settings are worth reviewing whenever you upgrade. The office.preview.type default and trust.host matching both changed across versions, so upgrades are not drop-in.

HotRepo's take

HotRepo's only recorded daily-board observation is 2026-10-28, when the project had 14,809 stars and gained 4 that day. A single snapshot cannot show whether interest is holding or fading, and the 2017 creation date says nothing about current maintenance. Treat the project as mature in age but budget time for a configuration review, especially the license status and the host-trust/upload settings, before putting it in front of untrusted users.