TeXworks pairs a TeX aware editor with a PDF viewer in one window

One window for editing TeX and reading the compiled PDF

TeXworks is an environment for authoring TeX documents, LaTeX and ConTeXt among them, with a Unicode based TeX aware editor, an integrated PDF viewer, and a clean simple interface. The word that matters in that list is integrated. The editor and the viewer are parts of the same application, so the document on screen and the typeset output on screen are one workflow rather than two programs you switch between.

The editor is TeX aware, which in practice means it knows about the structure of a TeX source file rather than treating it as plain text, and the whole editor is Unicode based, which for a language with accented names and non Latin scripts removes a class of encoding problems that older editors got wrong.

The intended user is explicit in the project's own description: the interface is meant to be accessible to casual and non-technical users, and the goal is a simple integrated environment rather than a professional tool with a steep learning curve. The repository topics list it as a text editor and a pdf viewer, which is the same statement in two words.

That positioning explains the design decisions. A tool aimed at command line typographers would offer a headless mode and a scripting interface first. TeXworks instead puts the mouse, the toolbar and the preview panel in front of the user.

TeXShop for macOS is the model the project copied deliberately

The README says TeXworks is inspired by Dick Koch's award-winning TeXShop program for macOS, which made quality typesetting through TeX accessible to a wider community of users without a technical or intimidating face. The stated goal is to deliver a similarly integrated, easy to use environment for users on all platforms, especially GNU/Linux and Windows.

That is a specific and useful piece of context, because TeXShop was already the reference implementation of the idea on one platform. TeXworks is not inventing a new interaction model; it is porting an established one, and the platform list in the description tells you where the gap was seen: Linux and Windows, where a comparable integrated environment was less common.

The comparison also sets a limit. Where TeXShop runs on macOS and integrates with that system's conventions, TeXworks has to work across three platforms with the same interface, which constrains how far the native integration can go. A feature that a Mac user would reach for a system service for will be a cross platform compromise instead.

The other thing the borrowed model implies is that the project is aimed at producing documents, not at managing a large multi file document set. The interface described in the README is a single editor and a single viewer, not a project browser.

Install by downloading a binary or by using a distribution package

Pre-built binaries for Windows, macOS and Linux are available for immediate download from the project website, and the README says the software is also known to be packaged in a set of distribution repositories, tracked through a repology badge on the project page.

That is the whole installation story, and it is deliberately unremarkable. There is no package manager to configure, no plugin system to activate before the editor is useful, and no account to create. A new user downloads the build for their platform and starts typing LaTeX.

The repository carries a continuous delivery workflow badge alongside a continuous integration badge, and a GitHub downloads badge that counts assets across releases. The presence of a release pipeline matters more than it might seem for a desktop application: it means the Windows, macOS and Linux builds are produced by the project rather than assembled by volunteers, which is what makes a single download the recommended path.

New users are pointed to a guide on the project website that outlines the fundamental process of creating, formatting and generating PDF documents from within TeXworks. That guide, rather than the README, is where the first-time workflow is documented.

Building from source needs Qt, Poppler, Hunspell and CMake

The build requirements are listed plainly. You need CMake, plus developer packages for Qt, Poppler and Hunspell, along with their dependencies such as Freetype, fontconfig and zlib. If you want the scripting plugins, you additionally need development packages for Lua and/or Python, and the details depend on the platform.

The version guidance is unusually generous. Using the latest stable versions of the dependencies is highly recommended, although TeXworks can be built with versions at least as old as CMake 3.1.0, Qt 5.2.3, Poppler 0.24.5 and Hunspell 1.2.9.

Those floor values tell you what the code has been kept compatible with, and they are old enough to raise a question about whether the recommendations are still current. The build notes carry a revision history: written by Jonathan Kew, updated in 2011, 2015 and 2019, and last updated on 2020-06-06 by Stefan Löffler. A six year old instruction set is worth verifying against the wiki pages before you start.

The sequence itself is standard. Once the dependencies are in place, you create a folder for building, run CMake inside it to generate a Makefile or an Xcode project, and then build with make or from Xcode. Platform specific instructions live in separate wiki pages for Windows with MinGW and for macOS with Homebrew.

SyncTeX ships as separate code with its own copyright

The licensing section is the one place where the project points at something other than its own code. TeXworks itself is copyright by Stefan Löffler, Jonathan Kew and Charlie Sharpsteen from 2007 to 2026, and distributed under the GNU General Public License version 2 or, at your option, any later version. The details are in the COPYING file.

The SyncTeX code is listed separately. It is copyright by Jérôme Laurens, with the years 2008 to 2024 given, and the README points to modules/synctex/synctex_parser.c for the licence details of that part. In practice this means that a distributor of TeXworks has to satisfy both the GPL terms for the application and whatever the SyncTeX file specifies, and anyone auditing a bundled copy has to read two files rather than one.

That arrangement is normal for code that originated elsewhere, and the SyncTeX parser is exactly the sort of component that arrives from another project. It is worth noting because the GPL statement alone does not describe the whole distribution.

For a project that people install on desktops, the practical consequence is small. It matters when you redistribute, when you package it for an operating system, or when you audit a copy in a regulated environment.

Source, modules, plugins and translations each sit in their own tree

The repository layout separates concerns more than a small desktop application usually needs to. There is src/ for the application code, modules/ for the separately licensed components, plugins-src/ for the scripting plugins that can be built against Lua or Python, res/ for resources, trans/ for translations, and unit-tests/ and testcases/ for the test suites.

The build system has its own directory in CMake/ alongside the top level CMakeLists.txt, and there are supporting trees for continuous integration in ci/, for packaging in PACKAGING, for platform glue in win32/, and for library patches in lib-patches/. GitArchiveInfo.txt at the root and the NEWS file sit alongside the release process.

The presence of unit-tests/ and testcases/ as separate trees tells you that both kinds of testing are expected: unit level checks and cases that exercise whole documents. The .appveyor.yml file at the root points at Windows continuous integration, alongside the GitHub Actions workflows for continuous integration and continuous delivery.

Translations are handled through Weblate, hosted outside the repository, with the README noting that translation efforts are hosted there and that any help is welcome. The trans/ directory in the tree is where the resulting catalogues are kept, and a contributor who adds a new string has to remember to update the translation workflow as well as the code.

A yearly release rhythm with the last tag from February 2026

The last push to the repository was on 2026-10-11 and the project is not archived. The release history shows TeXworks 0.6.11 published on 2026-02-10, 0.6.10 on 2025-02-13, and 0.6.9 on 2024-02-12.

That pattern is a yearly release, close to February each year, with the last three versions falling in three consecutive Februaries. A desktop application on an annual cadence is a deliberate choice rather than neglect: it means a user can install a build and expect it to keep working for a year, and it means the project can support several platforms at once without spending release engineering on every minor change.

The cost is that fixes reach users slowly. A crash found after the February release waits a year unless a patch release intervenes, and the gap between the current tag and the last push means the code on the main branch is already ahead of what most users have.

The licence is GPL-2.0 or later, which is a commercial friendly choice for a tool people redistribute freely, and the project also tracks its packaging status across distributions through repology, so a user on Linux may well receive the application from the distribution rather than from the project website.

Community support runs through the issue tracker, the mailing list, and Weblate for translations, with a code of conduct and a contribution guide in the repository.

Editorial conclusion

TeXworks suits a writer or student who wants to edit LaTeX and see the result without learning a command line toolchain, and it suits anyone who values a single window over a terminal oriented workflow. It does not suit a typesetter who wants scriptable, reproducible builds, since the project documents a graphical environment rather than a build pipeline you can drive from a shell, and it is a poor choice for a team that needs a current toolchain given that the build notes were last updated in 2020. Before adopting it, read the building page in the project wiki, check that your distribution of Qt, Poppler and Hunspell satisfies the stated minimums of CMake 3.1.0, Qt 5.2.3, Poppler 0.24.5 and Hunspell 1.2.9, and confirm that the SyncTeX code in modules/synctex carries its own separate licence terms before you redistribute it.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. TeXworks/texworks on GitHub