Convert a photo or texture image to a normal map
Creating a normal map from an image starts with the browser decoder for PNG, JPEG, or WebP. The converter scales oversized sources to the free 2K limit and calculates luminance without a server round trip. A grayscale height source is the most predictable input, but a photo or color texture can be useful for fast material blocking when you understand that color changes may become false depth.
Local generation runs inside this browser. Your source image is not sent to Normal Map Studio, FAL, or another model provider unless you deliberately open an AI workflow and confirm the upload disclosure.
- Drag, browse, paste, or load the built-in procedural sample.
- Compare source and output without losing your current settings.
- Undo and redo parameter changes before export.
- Download one map or package the generated set as a ZIP archive.
Choose an input that produces cleaner normals
Even, diffuse lighting gives the luminance gradient a better chance of matching physical relief. Specular highlights, cast shadows, text, and color-only boundaries often create unwanted grooves. If you have a dedicated height map, use it. If you only have a photo, lower strength, add a small blur, and inspect the sphere preview from several light directions.
Seamless sources benefit from wrapped edges. Non-tiling photos usually look better with clamped edges because opposite sides do not describe neighboring texels. The edge option changes sampling during generation; it does not claim to reconstruct missing material outside the frame.
Export with the renderer in mind
Use the Unreal Engine preset for the common DirectX green direction. Unity projects may use either convention depending on texture import settings and render pipeline, so verify a small material first. Blender commonly expects OpenGL direction. Godot defaults can also depend on how the texture is imported, making the explicit format label more reliable than guessing from a filename.
Normal Map Studio exports ordinary PNG files. It does not apply engine-specific compression, because compression belongs in the destination project where color space, bit depth, and platform settings are known.
Sprites, icons, and flat artwork
Flat artwork is a different problem from a photographed surface. A sprite, a UI icon, a logo, or a pixel-art tile usually has crisp edges and uniform interior colour, so a luminance conversion produces a strong slope at every outline and nothing inside the shape. The result is a bevelled outline rather than a surface, which can be exactly what you want for a chunky button or a sticker effect, and is not what you want if the artwork is meant to read as a textured object.
For this kind of input, keep the strength low and leave blur near zero. A large blur turns the crisp edge into a wide soft ramp that reads as a rounded edge, which is a different look. If the artwork already contains internal shading, the conversion will interpret that shading as shape, and the result often needs the interior flattened or the shading removed before conversion.
Alpha is worth deciding deliberately. A sprite with transparent regions has no colour outside the shape, and how the converter treats those texels changes the border slope. Leaving them clamped generally produces a cleaner edge than letting the transparent area contribute a ramp. Check the border of the shape in the 3D preview, where an incorrect edge treatment is easier to see than in the flat output.
Confirm the result at the size the sprite will be displayed. A bevel that looks convincing at full zoom often disappears when the icon is drawn at 32 pixels, and detail that is invisible at full zoom can dominate once the texture is minified. Generate for the display size rather than for the source size.
Checking the result before you export
Use the movable light in the 3D preview as the primary check. A correct normal map responds consistently as the light travels: highlights move across the surface in the direction you expect, and a bump keeps facing outward from every angle. An incorrect map still produces a plausible image from one fixed light, which is why a single screenshot is not enough evidence that the conversion worked.
Look for the classic failure shapes. A dent that renders as a bump means the vertical direction is reversed. A surface that appears to be lit from the opposite side of the light means the green channel convention does not match the renderer. A uniform grey area in the output means the source had no gradient there, so there is no slope to encode, and no amount of strength will create one.
Compare the output against the source at the same zoom, side by side. Details that exist in the source but not in the map are usually below the sampling threshold and point at resolution rather than at parameters. Details that exist in the map but not in the source are noise and are usually fixed by a small blur before the derivatives are calculated.
Export one channel and test it in the destination material before generating a full set. Importing a single normal map, setting it to non-colour data, and lighting it takes a minute and catches the convention and colour-space mistakes that are otherwise discovered after an entire set has been produced and named.
Fixing a conversion that came out wrong
Most wrong-looking conversions trace back to the input rather than to the settings. Baked-in shadows produce ridges and grooves that follow the lighting rather than the surface. Strong colour variation produces false depth wherever hue changes without a corresponding shape change. Specular highlights produce isolated peaks. None of these are parameter problems, and correcting them with strength or blur trades one artefact for another.
When the input is the problem, change the input. Level the lighting, desaturate before conversion if colour is unrelated to shape, remove obvious highlights, or supply an actual height map. If the source is a scene with real geometry and the light cannot be levelled, a depth estimate is the more appropriate workflow because it infers shape from context rather than from brightness.
If the input is fine and the result is still wrong, check the convention and the colour space before touching anything else. The normal map must be imported as non-colour data, and the green-channel direction must match the renderer. Those two settings account for most reports of an inverted or oddly lit surface, and both are quick to verify on a single test object.
Keep the settings that worked. Once a source, a parameter set, and a convention produce a good result, record them together so the next texture in the same material family starts from a known-good baseline instead of from defaults.