# DirectXTex: the Microsoft library for reading DDS and converting texture formats

> DirectXTex is the MIT licensed C++ library behind texconv, covering DDS, TGA, HDR and WIC formats plus resizing, mip generation and block compression. The tooling is mature, and the packaging advice in the README changed recently.

**microsoft/DirectXTex** — DirectXTex texture processing library

- Repository: https://github.com/microsoft/DirectXTex
- Website: https://walbourn.github.io/directxtex/
- Stars: 2,161 · Forks: 503
- Language: C++
- License: MIT
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-directxtex

## What the library covers and which header is actually public

DirectXTex is a shared source library for reading and writing `.DDS` files and doing texture processing: resizing, format conversion, mip-map generation, block compression for Direct3D runtime texture resources, and height-map to normal-map conversion. It also reads and writes `.TGA` and `.HDR`, which the README explains are commonly used in texture pipelines but have no built-in WIC codec.

The detail that saves people an afternoon is which headers to include. The README states that the majority of header files in the `DirectXTex/` directory are for internal implementation only, naming `BC.h`, `BCDirectCompute.h`, `DDS.h` and `DirectXTexP.h` as examples. Only `DirectXTex.h` and `DirectXTex.inl` are the public header. Reaching into the others is the most common way to build something that breaks on the next release.

The library depends on the Windows Image Component, or WIC, for bitmap formats. That gives it BMP, JPEG, PNG, TIFF and HD Photo through one path, which is why the WIC-based reader and writer sits alongside the DDS, TGA and HDR ones rather than replacing them.

## texconv is the tool you will actually run

The `Texconv/` directory holds a reimplementation of the DirectX SDK's texconv utility, built on DirectXTex instead of the retired D3DX libraries. The README is precise about compatibility: it supports the same arguments as the legacy `_Texture Conversion Tool Extended_` tool, with two exceptions. The `-10` and `-11` arguments do not apply, and the filter names differ, so instead of `POINT`, `LINEAR`, `CUBIC`, `FANT` or `BOX` and `TRIANGLE` you get `*_DITHER` and `*_DITHER_DIFFUSION`.

That is a migration cost worth budgeting for. A build script written against the old texconv will mostly work, but filter names will change behaviour or fail, and the two dropped arguments need replacing. The library also adds support for the JPEG XR, or HD Photo, bitmap format, which the original did not handle this way.

Two more command-line utilities sit alongside it. `Texassemble/` builds cubemaps, volume maps and texture arrays from a set of individual input image files, which is the tool you reach for when authoring an array texture rather than converting one. `Texdiag/` analyses image contents and exists mainly for debugging, printing what a file actually contains rather than converting it.

## Two loaders, and the README tells you which to pick

The runtime story is the part with a genuine trade-off, and the README is unusually direct about it. There are two loaders in the tree and they are not interchangeable.

`DDSTextureLoader/` is a streamlined version of the legacy DirectX SDK sample, intended for simple, lightweight runtime loading. It performs no runtime pixel data conversions at all, and it supports the full complement of Direct3D texture resources: 1D, 2D, volume maps, cubemaps, mipmap levels, texture arrays and BC formats. The `DDSView/` sample is a Direct3D 11 viewer for DDS files where the `<` and `>` keys step through array slices and `1` through `0` jump to a specific image index, which is a quick way to verify what a conversion produced.

`WICTextureLoader/` takes an ordinary image file, resizes it based on the current feature level or an explicit parameter, converts it to a DXGI_FORMAT if needed, and creates a 2D texture. Its limitation is stated plainly: no 1D textures, no volume textures, no cubemaps, no texture arrays. The README's guidance is that DDSTextureLoader suits fully precooked textures for maximum performance and image quality, while the WIC loader is for making a simple 2D texture from a standard image file at runtime. Both come in Direct3D 9, 11 and 12 versions, and the README notes stand-alone variants of these modules exist in the DirectX Tool Kit for DX11 and DX12.

## Build configuration, and the clang-format version trap

This code targets Visual Studio 2022, Visual Studio 2026, clang for Windows v12 or later, or MinGW, and requires the Windows 11 SDK at version 22000 or later when using Visual Studio. It can also be built for the Windows Subsystem for Linux with GCC 11 or later. The CMake projects require 3.21 or later, and the tree contains several solution files including `DirectXTex_Desktop_2026.slx` and the `.slnx` format variants.

The formatting requirement is the unusual one. The README states that clang-format use for this project must match the version used by GitHub Super-Linter to pass validation, and that Visual Studio 2022 and 2026 ship different versions, so you need to pin one:

```cmd
winget install --id=LLVM.LLVM --version 21.1.2
powershell -File build/Format.ps1 -LLVM
```

This is a small thing that generates real friction in a large team. If your CI runs Super-Linter and your developers format with the compiler bundled clang-format, contributions will keep failing on formatting that is correct for your toolchain and wrong for the repository's.

The tree also holds `.azuredevops/` for the build definition, `.onefuzz/` for fuzzing, `.nuget/` for packaging, and `build/` for the miscellaneous scripts including that `Format.ps1`. The presence of a fuzzing configuration is a reasonable signal about how the image parsers are treated, which is the right place to be careful given they parse untrusted files.

## A NuGet deprecation that changes your integration path

This is the sentence in the README most likely to affect an existing pipeline: the `directxtex_desktop_win10` and `directxtex_uwp` NuGet packages are deprecated, and the recommended way to integrate the latest DirectXTex into a C++ project is now vcpkg. The release notes for the May 7, 2026 build repeat the point, listing NuGet packages at version 2026.5.8 and noting that this version is available via vcpkg.

So the packaging story has moved from NuGet to vcpkg, and the deprecation is explicit rather than implied. If you inherited a project consuming one of those packages, that is a known future migration rather than a surprise, and the vcpkg port is the destination. The releases themselves are also distributed through winget, with the three tools published individually as Microsoft.DirectXTex.Texassemble, Microsoft.DirectXTex.Texconv and Microsoft.DirectXTex.Texdiag.

There is also an API change to note rather than just a packaging one. Starting with the October 2025 release, the Auxiliary functions for loading and saving JPEG and PNG files take a flag parameter. Anything in `Auxiliary/` that you call directly needs checking against that signature. That directory holds the optional extras, including adapter loading functions using the OpenEXR library and Xbox texture tiling extensions, so it matters if you took a dependency on any of them.

## Maintenance pace and where the documentation lives

The release cadence is roughly every two to three months, with tags named by month rather than version number. Three releases are visible in the recent history: `oct2025` published on 2025-10-28, `mar2026` on 2026-03-31, and `may2026` on 2026-05-08. The last push to the repository was on 2026-09-22, so work was still landing after the newest tag.

What the changelogs fix is informative about the risk profile. The May 2026 release carries an HDR reader fix for an out-of-bounds read when reading a malformed header, and the March 2026 release includes an HDR reader validation fix for a malformed header that could result in a buffer over-read. Two of the most recent releases fixing malformed-header reads in the same reader tells you where the sharp edges are, and it is worth noting if you accept textures from outside your pipeline.

Documentation is on the GitHub wiki rather than in the repository. The README points there and separately notes that `CHANGELOG.md` holds the full change history, `SECURITY.md` covers reporting and the GitHub security advisories page is where vulnerabilities are published. The `skills/` directory is new enough to be worth a look too, since it holds published CoPilot skills for developers, and the README shows how to install one:

```bash
gh skill install microsoft/directxtex
copilot
/skills list
```

## Conclusion

DirectXTex is the sensible default if you ship Direct3D content, because the format coverage and the block compression paths are the part that is genuinely hard to replace, and the MIT licence keeps the legal question trivial. It is also usable on Linux under WSL, though the tool binaries are a Windows-first proposition. Read the packaging note before you wire it into CI, because the directxtex_desktop_win10 and directxtex_uwp NuGet packages are deprecated and the README now points at vcpkg as the supported route, which means an existing pipeline pinned to those packages is running on borrowed time. Two other specifics to carry into your plan: the public surface is DirectXTex.h and DirectXTex.inl only, and the Auxiliary JPEG and PNG helpers gained a flag parameter in the October 2025 release, so check that signature against your call sites.

## FAQ

### What image formats can DirectXTex read and write?

DDS is the core format, with TGA and HDR readers and writers included because they are common in texture pipelines and have no built-in WIC codec. WIC handles BMP, JPEG, PNG, TIFF and HD Photo, and the Auxiliary layer adds EXR-based adapter loading.

### How do I install DirectXTex in a C++ project?

The README states that the directxtex_desktop_win10 and directxtex_uwp NuGet packages are deprecated and that vcpkg is the recommended way to integrate the latest version. The vcpkg port is microsoft/vcpkg under ports/directxtex, and the CMake projects need CMake 3.21 or later.

### What is the difference between DDSTextureLoader and WICTextureLoader?

DDSTextureLoader performs no runtime pixel conversions and supports 1D, 2D, volume maps, cubemaps, mip levels, texture arrays and BC formats, so it suits pre-cooked assets. WICTextureLoader resizes and converts ordinary image files at runtime but supports only 2D textures.

### Is texconv from DirectXTex a drop-in replacement for the DirectX SDK version?

Mostly. It supports the same arguments as the legacy texture conversion tool except -10 and -11, and the filter names differ, using variants like *_DITHER and *_DITHER_DIFFUSION instead of POINT, LINEAR, CUBIC, FANT, BOX and TRIANGLE. It also adds JPEG XR and HD Photo support.

### What license is DirectXTex released under?

MIT. The README states that all content and source code for the package is subject to the terms of the MIT License, and security advisories are published on GitHub.

## Sources

- [License: MIT](https://github.com/microsoft/DirectXTex/blob/main/LICENSE)
- [microsoft/DirectXTex on GitHub](https://github.com/microsoft/DirectXTex)
- [Project website](https://walbourn.github.io/directxtex/)
- [README](https://github.com/microsoft/DirectXTex/blob/main/README.md)
- [Releases](https://github.com/microsoft/DirectXTex/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-directxtex