Better ClearType Tuner: a Windows font smoothing panel that shows which rendering path an app uses

Why the built in ClearType tuner is not usable as shipped

The stated premise of this project is that the ClearType tuner built into Windows is broken, and the replacement is not a bigger feature list but a narrower, honest one. The README says the program quickly sets font smoothing settings in Windows 7, 10, or 11 and lets you know what you are getting, unlike the built in tuner, and that it includes all the font smoothing settings the author found to work in modern Windows while not exposing settings that are non functional.

That filtering decision is the design. A control panel that shows every registry knob Windows has ever had is a trap, because most of them do nothing on a current install, and there is no way to tell from the interface which is which. This one shows only the working set, and backs that claim with previews.

The settings it does expose are grouped into three areas. You can enable or disable font antialiasing. You can choose between grayscale antialiasing and subpixel antialiasing using RGB or BGR subpixel layouts, with the README noting that ClearType technology specifically refers to the RGB and BGR subpixel antialiasing modes. And you can edit the text contrast and other text rendering settings.

There is also a preview surface, which is the part that makes the tool worth using rather than merely useful. You can preview the results at several font sizes and see a zoomed-in view, and every setting is previewed live through all three of the rendering paths Windows actually uses: GDI, DirectWrite ClearType, and DirectWrite grayscale. The zoom matters because a subpixel layout is invisible at normal reading size.

The primary language is C#, and the repository is a Visual Studio solution, BetterClearTypeTuner.sln, with a BetterClearTypeTuner project directory and a BCT_Tests directory. The licence is GPL-3.0.

How to get it: a zip with two builds and a config file to keep

There is no package manager path here. The README says to download from the Releases Section, extract, and run. The release page is the only distribution channel the project documents.

The zip contains two builds of the same program, and the instruction is to run whichever one suits your machine and keep its .exe.config file next to it. The two executables and their requirements are the whole selection guide. BetterClearTypeTuner.exe requires .NET Framework 4.7.2, works on Windows 7 SP1 and later, runs as x86 or x64 under emulation on ARM, and is the one to use unless you have a reason not to. BetterClearTypeTuner-ARM64.exe requires .NET Framework 4.8.1, needs Windows 10 or later, and runs natively on Windows on ARM (24H2+) instead of under x64 emulation. Despite the name it is an AnyCPU build and runs on x86 and x64 too.

Two details in that table are easy to get wrong. The file named ARM64 is not an ARM64-only build, it is an AnyCPU build that avoids x64 emulation on ARM machines, and it still runs on x86 and x64. And the two executables need different .NET Framework versions, with 4.7.2 for the standard build and 4.8.1 for the ARM one, which is a consequence of running natively on Windows on ARM rather than under emulation.

The .exe.config file is the part people lose. The README says to keep it next to the executable, which implies the program reads configuration from alongside itself rather than from a user directory. If you move the exe somewhere and leave the config behind, the behaviour is not what the author tested.

The default advice in the README is to use the standard BetterClearTypeTuner.exe unless you have a reason not to, which is the right call for almost everyone, and the ARM64 variant only earns its place on an ARM machine running Windows on ARM 24H2 or later.

Three rendering paths, and the table that explains why apps disagree

This is the core of the project and the part the README spends most of its words on. Windows has two low level text rendering methods, GDI and DirectWrite, and apps typically use one or the other. But DirectWrite is not one thing. It rasterizes glyphs down one of two paths, and each application chooses for itself.

The README gives the mapping directly, as a two column table with a ClearType path column and a grayscale path column. Coverage is computed per color subpixel on the first and one value per whole pixel on the second. The typical apps listed are Firefox, Edge and WPF for the ClearType path, and Settings, WinUI and Store apps for the grayscale path. GammaLevel applies on both. EnhancedContrastLevel applies only on the ClearType path, and GrayscaleEnhancedContrastLevel only on the grayscale path. ClearTypeLevel and PixelStructure apply only on the ClearType path.

Read that table row by row and the behaviour of individual applications stops being mysterious. GammaLevel applies to both paths. EnhancedContrastLevel applies only on the ClearType path, and GrayscaleEnhancedContrastLevel only on the grayscale path, which is why a setting that visibly changes one app does nothing in another. ClearTypeLevel and PixelStructure exist only for the subpixel path.

The concrete example given is Firefox, which is known to use DirectWrite, but in the author's tests ignores the Enhanced Contrast setting. That is the exact symptom people report when a ClearType tool appears not to work.

The reason WinUI apps behave differently is structural rather than a bug. A WinUI app draws its text onto composition surfaces that may be transparent, transformed or animated, and those surfaces cannot carry per subpixel coverage, so it rasterizes grayscale no matter which antialiasing mode you selected.

The consequence for a user is stated plainly: the selected antialiasing mode controls GDI based apps fairly reliably, but is only a hint to DirectWrite apps, so apps may end up using a different antialiasing mode than what you selected. Nothing in the tool can fix that, and the honest response is to look at the three previews and see which is which.

Better ClearType Tuner previews both DirectWrite paths side by side, live, so you can see which setting moves which.

Registry writes moved to HKCU, and the one case that still needs admin

The most user visible change in recent versions is that administrator permission is no longer needed to change text rendering settings. Everything going into the Windows Registry is written under HKEY_CURRENT_USER now.

The README explains why the earlier behaviour was pointless. Versions up to 1.6.2 also wrote GammaLevel and PixelStructure under HKEY_LOCAL_MACHINE, and that required administrator permission. It had no benefit because the keys under HKCU override the keys under HKLM anyway. So the elevated versions were writing a machine wide key that the per user key shadowed regardless.

That is a good example of a change that removes friction without changing the outcome, and it is why 1.7 and 1.6.2 landed on the same day in August 2026, with 1.6.2 being the last of the machine wide writing versions and 1.7 the per user rewrite.

There is exactly one case where a UAC prompt can still appear: clearing Override DirectWrite defaults on a machine where an older version of this program, or another tuner, left a machine-wide key behind, since removing that still requires administrator rights. So the first run of 1.7 on a machine that previously used 1.6.2 may still ask for elevation, and the reason is cleanup rather than the settings themselves.

The Override DirectWrite defaults checkbox decides whether the Avalon.Graphics registry key exists at all. A clean Windows installation does not have it, and the README points out that this is not always the same as having it with default looking values in it. DirectWrite falls back to settings of its own, and at least some applications behave differently depending on whether the key is there or missing. Clearing the checkbox removes the keys from the Windows Registry, and the settings boxes then show what DirectWrite falls back to, read from DirectWrite itself rather than assumed.

That last detail is the design principle of the whole tool. Where a value can be read from the system, it is read, and where it is a guess, the guess is not shown as fact.

GammaLevel defaults, the missing TextContrastLevel, and per monitor settings that do not work

Three specific gaps are documented, and they are worth reading before you file a bug.

The first is a documented default that does not match reality. Microsoft documents the Avalon.Graphics GammaLevel default as 1900, but the README says experiments show that DirectWrite does not use that number. When the DirectWrite API is asked what it resolves to with the key absent, it answers with a gamma of 1.8, a GammaLevel of 1800. So the value you see in a fresh system is not the value the documentation promises, and the program reads the real one.

The second is an intentional omission. TextContrastLevel is the one Avalon.Graphics value still not exposed by Better ClearType Tuner. The reason given is that it is a WPF 3.5 era setting with no reader the author could find in modern Windows. The program does not leave the key out, it writes the value at its documented default of 1, so that the full set of keys exists in case something the author is not aware of cares to read it. That is a careful compromise: the setting is not offered as a control, but the registry state is complete.

The third is per monitor text settings. DirectWrite text rendering appears to have been designed with support for having different text rendering settings on different monitors. However, this appears to be entirely non-functional in modern Windows, so the program sets Avalon.Graphics registry keys for all monitors the same.

The README links to the supporting material for that last point, and the references explain the mechanism. Microsoft documents per-display WPF and Avalon keys such as PixelStructure under SOFTWARE\Microsoft\Avalon.Graphics\<display>, while GDI font smoothing orientation is a single SystemParametersInfo value with no monitor handle. DirectWrite can load per-HMONITOR defaults only when apps call CreateMonitorRenderingParams, so a DirectWrite app that never calls it has no way to pick up per monitor values.

The project also links its own investigation notes in a ClearType Investigations wiki, a discussion in issue 11, and an independent mapping of what each step in the ClearType Text Tuner does. That last reference matters for comparison, because it lets you work out what a given cttune.exe action actually wrote to the registry, and therefore what a different tuner is doing differently.

The version history is short and recent: 1.6.1 and 1.6.2 on 2026-08-11, then 1.7 on the same day, and the last push was on 2026-08-11.

Editorial conclusion

Better ClearType Tuner fits a Windows user or administrator who wants font antialiasing, subpixel layout and contrast settings applied per user without an elevation prompt, and who wants to know which of the three text rendering paths a given app uses. It is the wrong tool if you need per monitor text settings, because the project states that capability is non-functional in modern Windows, or if you need the Avalon.Graphics TextContrastLevel value, which the program does not expose. Before adopting, read the caveats section rather than the features list, since the difference between the ClearType path and the grayscale path is exactly what determines whether your settings will have any effect in a given application.

Frequently asked questions

Official sources

1. bp2008/BetterClearTypeTuner on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases