DDS Format: DirectX Game Textures & 3D Assets

Origin and purpose

DDS (DirectDraw Surface) is Microsoft's container format for GPU-ready texture data, introduced as part of DirectX 7 in 1999. The format was designed for a specific problem: loading textures into graphics hardware as quickly as possible, with the data already in the format the GPU expects.

A normal image format — PNG, JPEG, WebP — needs decoding before the GPU can use it. The CPU reads the file, decompresses it, and uploads raw pixel data to the GPU. For a game with hundreds of textures, this decode step is a significant cost.

DDS short-circuits the process by storing textures in formats the GPU can read directly. Modern GPUs support several "block compression" formats (DXT, BC, ASTC, ETC) that compress textures while still allowing fast random pixel access during rendering. DDS files contain these pre-compressed blocks; the GPU loads them as-is.

This is the format's defining advantage: zero-decode upload to graphics memory. It is the standard texture format in PC game development and remains widely used in 3D rendering pipelines, game engines, and any application where textures must be loaded fast and stay GPU-resident.

File structure

A DDS file consists of:

Magic bytes (4 bytes) — "DDS ".
Main header (124 bytes) — dimensions, mipmap count, pixel format identifier, surface flags.
Optional DX10 header (20 bytes) — added for newer DirectX 10+ formats (BC4, BC5, BC6H, BC7).
Pixel data — the actual texture data, ordered by mipmap level (largest to smallest) and by face for cubemaps.

The pixel format identifier specifies one of dozens of supported compression formats. The most important are the BC (Block Compression) family:

Format	Bits per pixel	Channels	Best for
BC1 (DXT1)	4	RGB (1-bit alpha)	Diffuse textures, no alpha
BC2 (DXT3)	8	RGBA (4-bit alpha)	Sharp-edged alpha
BC3 (DXT5)	8	RGBA (interpolated alpha)	Smooth-edged alpha, most common
BC4	4	Single channel	Greyscale heightmaps, masks
BC5	8	Two channels	Normal maps
BC6H	8	HDR RGB	HDR textures
BC7	8	RGBA (high quality)	Best general-purpose, newer hardware

Each block compresses a 4×4 pixel region using one of these schemes. The compression is lossy but designed so that the visual quality holds up at typical game rendering distances and resolutions.

Mipmaps

DDS files typically store multiple "mipmap" levels of each texture: the full resolution, plus half-size, quarter-size, eighth-size, and so on down to 1×1.

Mipmaps solve a rendering problem. When a texture is drawn at a smaller size than its native resolution — for example, when an object is far from the camera — using the full-resolution texture causes shimmer and aliasing as the GPU samples sparse pixels from the dense texture. Pre-computed mipmaps let the GPU sample from a level that matches the rendered size, producing smoother, faster output.

The full mipmap chain for a 1024×1024 texture stores 11 levels totalling roughly 1.33× the storage of the base level alone — a 33% storage overhead for substantial rendering quality improvement.

Cubemaps and texture arrays

DDS supports several texture topologies beyond plain 2D images:

Cubemap — six 2D textures arranged as the faces of a cube. Used for environment reflections, skyboxes, image-based lighting.
Volume texture — a stack of 2D slices forming a 3D texture. Used for medical imaging, volumetric effects, 3D lookup tables.
Texture array — multiple textures sharing the same dimensions and format. Useful for sprite sheets and terrain texturing.

A single DDS file can contain any of these, with full mipmap chains for each layer.

Why DDS is fast

The performance characteristics that make DDS valuable in game pipelines:

Zero CPU decode. The GPU reads the compressed blocks directly.
GPU-native compression. Block-compressed textures fit in less GPU memory than uncompressed, allowing more textures to be resident.
Pre-computed mipmaps. No runtime mipmap generation.
Random access. The GPU can read any pixel without decoding the whole texture.
Bandwidth efficiency. Less data transferred from system memory to GPU memory.

The trade-off: encoding DDS textures with good visual quality takes meaningfully longer than encoding to JPEG or WebP. Build pipelines often spend more time on texture compression than on any other asset processing step.

Browser support

Most web browsers do not natively render DDS. WebGL and WebGPU do support uploading block-compressed texture data through specific extensions:

WEBGL_compressed_texture_s3tc — DXT1, DXT3, DXT5 in WebGL.
EXT_texture_compression_bptc — BC6H, BC7 in WebGL.
WebGPU texture formats — equivalent support in the newer WebGPU API.

In other words: web games that use WebGL or WebGPU can use the same compressed texture formats DDS stores, often loaded via custom loaders that parse DDS or KTX2 (a more web-friendly container) files. But standard <img> tags do not render DDS, and that's not the use case.

DDS vs KTX2 vs other texture formats

For modern texture pipelines:

DDS — Windows/DirectX-centric, widely supported in game engines, mature tooling.
KTX2 — Khronos Group standard, designed for OpenGL/Vulkan and increasingly used for cross-platform game and web 3D content.
Basis Universal — a "supercompressed" format that transcodes to any GPU compression format at load time. Used heavily for web 3D content.
PNG/JPG/WebP — for "source" textures that get processed into compressed formats at build time.

The typical pipeline:

Artists create textures in PSD, PNG, or TIFF as source files.
Build pipeline compresses to DDS (Windows-only), KTX2 (cross-platform), or Basis Universal (web).
Game engine loads the compressed textures.
GPU samples them at runtime.

Encoding tooling

The standard tools for DDS encoding:

NVIDIA Texture Tools (nvtt) — the historical reference encoder. Comes with nvcompress CLI.
AMD Compressonator — alternative reference encoder with good cross-format support.
Microsoft DirectXTex (texconv) — Microsoft's modern reference encoder. Supports all BC formats including BC6H and BC7.
crunch — open-source encoder optimised for fast encoding speeds.
ImageMagick — supports DDS reading and writing for basic cases.

# DXT5 compression for diffuse texture with alpha
texconv -f BC3_UNORM input.png

# BC7 compression for highest quality
texconv -f BC7_UNORM input.png

# BC5 for normal maps
texconv -f BC5_UNORM normal.png

Encoding speed varies enormously by format. BC1/DXT1 is fast (milliseconds per texture); BC7 with high-quality settings can take seconds per texture. Build pipelines balance encoding time against visual quality and final file size.

Web use

For 3D content on the web, the modern recommendation is Basis Universal or KTX2 rather than DDS. The reasoning:

DDS uses formats specific to particular GPU vendors. A DDS encoded with BC formats works on desktop GPUs but not on most mobile GPUs (which use ASTC or ETC).
KTX2 supports universal texture formats and transcodes to the GPU-native format at load time.
Basis Universal solves the same problem with a single supercompressed format.

For non-3D web content (regular site graphics, photos, UI elements), DDS is never the right choice. Use WebP, AVIF, or PNG.

When to use DDS today

Choose DDS when:

The target is a Windows/DirectX game or application.
The pipeline benefits from pre-computed mipmaps and zero-decode upload.
The asset will be consumed by a renderer that explicitly supports DDS.
The build pipeline already produces DDS textures and the convention is established.

Choose other formats when:

The target is the web (use Basis Universal or KTX2 for 3D content; WebP/AVIF for everything else).
The target is cross-platform (use KTX2 or platform-appropriate formats).
The image is for general viewing rather than GPU consumption.

Modern relevance

DDS matters for:

PC game development. The default texture format for Windows/Xbox games using DirectX.
3D rendering pipelines that use compressed textures for performance.
Game asset modding — many popular games' modding communities work with DDS files.
Unreal Engine, Unity, and other game engines — all support DDS import, often with build-step conversion to platform-appropriate formats.

DDS does not matter for:

Web image display — no browser renders it.
General photography and graphics — use PNG, JPEG, WebP.
Vector content — use SVG.
Cross-platform texture pipelines without DirectX — KTX2 or platform-native formats fit better.