Your pack never leaves your device. Reading the archive, remapping texture paths, rewriting the metadata and rebuilding the output all happen here in your browser; this page makes no network requests with your file.
One pack at a time. Java packs are .zip, Bedrock packs are .mcpack (a renamed zip). The tool detects which edition it is.
Texture path mapping is derived from Mojang/bedrock-samples (main @ 46d8171). It maps 944 of 1,273 block textures (74%) and 955 of 1,660 item textures (58%). Names with no clean equivalent are passed through with a best-effort path and counted in the report above. Many Bedrock block-item icons are drawn from the block model, so they have no item texture file to map to.
A resource pack converter takes a Minecraft pack built for one edition and rewrites it for the other. Drop in a Java .zip or a Bedrock .mcpack, pick a direction, and the tool remaps texture paths, rebuilds the metadata, and hands you a pack you can load in the target edition. It all happens in your browser, so nothing uploads and there is no watermark.
Java and Bedrock store textures very differently. Java keeps each texture at a path like assets/minecraft/textures/block/stone.png, while Bedrock resolves block and item textures through terrain_texture.json and item_texture.json, with many files renamed in the 1.13 flattening. Moving a pack across editions means more than copying files: every texture has to land at the right path under the right name.
On top of textures, the converter translates the pack metadata (Java pack.mcmeta to and from a Bedrock manifest.json with generated UUIDs), sounds, animated textures and language files, and can also bump a Java pack's pack_format for a different version. Each category is a checkbox, so you decide what carries over.
The heart of the tool is a derived Java-to-Bedrock texture map. It is built from Mojang's own bedrock-samples resource pack: terrain_texture.json and item_texture.json give the canonical Bedrock texture ids and file paths, and the actual texture files in the sample pack provide the rest. Each Java texture name is matched to its Bedrock path by id first, then by the documented rename rules from the flattening (logs split into side and top, doors into lower and upper, spawn eggs and boats reordered, adjective-noun swaps like golden_apple to apple_golden).
When a match exists, the texture is written to the correct Bedrock path and the right index files are generated so it resolves in game. When no clean match exists, the texture is passed through with a best-effort path and flagged so nothing is lost quietly. After every conversion the tool reports how many textures were remapped, how many passed through, and which features could not convert at all, with counts. The mapping coverage is shown on the page so you always know what fraction of names the map covers.
Realistic shader packs add physically based rendering data on top of the flat color texture. Java uses the community LabPBR standard: each texture gains an _n.png normal map (normal X and Y, plus ambient occlusion and height packed into the blue and alpha channels) and an _s.png specular map (perceptual smoothness, F0 or metalness, porosity and subsurface scattering, and emissive). Bedrock RTX takes a different shape: a per-texture texture_set.json that points at a MER map (red metalness, green emissive, blue roughness) and a separate normal map.
With the PBR category on, the converter rebuilds these maps pixel by pixel on a canvas in your browser. Roughness is the inverse of smoothness, emissive carries straight across, and the LabPBR metal range (green 230 to 255) becomes full Bedrock metalness; the normal map keeps its X and Y and reconstructs Z. The conversion is deliberately honest about its limits: Bedrock has no slot for LabPBR ambient occlusion, height, porosity or subsurface scattering, and a single Bedrock metalness scalar cannot encode LabPBR predefined-metal ids, so those channels are dropped or defaulted and the result panel says so. It gives you a working material set to refine rather than pretending the formats are identical.
Some things genuinely do not translate. Java custom block and item models and blockstates use a system Bedrock does not share; Java core and post shaders (the .fsh and .vsh programs, not PBR material maps), custom fonts, and OptiFine or CTM features have no Bedrock resource-pack equivalent. In the other direction, Bedrock JSON UI, entity geometry, attachables and render controllers have no Java form.
Rather than pretend these convert, the tool detects them and lists them in an itemized not-converted report after each run, with the file count and a short reason for each group. That keeps the output honest: a simple texture and metadata pack converts almost completely, while a complex pack with custom models converts its textures and tells you exactly what was left behind to fix by hand. Everything runs locally and makes no network calls with your pack.
Yes. Drop in your Java pack .zip, choose Java to Bedrock, and download a .mcpack. The tool remaps every block and item texture from Java's assets/minecraft/textures paths to the Bedrock layout (textures/blocks and textures/items) using a name map derived from Mojang's own Bedrock sample pack, writes the terrain_texture.json and item_texture.json index files, and generates a manifest.json with fresh UUIDs. Bedrock to Java works the same way in reverse.
Block and item textures, PBR shader materials (LabPBR _n and _s maps to and from Bedrock RTX texture sets), pack metadata (pack.mcmeta to and from manifest.json), sounds (sounds.json to and from sound_definitions.json), animated textures (Java .mcmeta to and from Bedrock flipbook_textures.json) and language files (Java JSON to and from Bedrock .lang) are converted. Many features still have no cross-edition equivalent: custom block and item models, blockstates, Java core and post shaders, custom fonts, and OptiFine or CTM extras. Those cannot convert, so the tool lists them in an itemized not-converted report with counts instead of dropping them silently.
Yes, with the PBR category turned on. Java shader packs use the LabPBR standard, where each texture gets an _n.png normal map (normal XY plus ambient occlusion and height) and an _s.png specular map (smoothness, F0 or metalness, porosity and subsurface scattering, and emissive). Bedrock RTX uses a per-texture texture_set.json that points at a MER map (red metalness, green emissive, blue roughness) and a separate normal map. The tool remaps these per pixel: roughness is the inverse of smoothness, emissive carries straight over, and the LabPBR metal range 230 to 255 becomes full Bedrock metalness. It is honestly lossy in places, which the result panel spells out.
The two formats do not store the same data. Going Java to Bedrock, LabPBR ambient occlusion and height (carried in the normal map's blue and alpha channels) are dropped because Bedrock's normal layer is RGB only and its heightmap layer is mutually exclusive with it, and LabPBR's predefined metal F0 values flatten to a single metalness scalar. Going Bedrock to Java, porosity, subsurface scattering, ambient occlusion, height and the specific metal id do not exist in a Bedrock texture set, so those LabPBR channels are filled with safe defaults rather than real data. The converted materials are a strong starting point that may want a manual touch-up for a showcase pack.
Yes. Reading the archive, remapping texture paths, rewriting metadata and rebuilding the output all run in your browser with an in-page zip library. The page makes no network requests with your pack, so the file never leaves your device and there is no watermark or account.
pack_format is the number in a Java pack.mcmeta that tells Minecraft which game version the pack was built for. If it does not match your client, the game shows an incompatible warning. The Java version update direction rewrites pack_format to the version you choose and adds a wide supported_formats range so the pack loads cleanly across many versions without re-authoring any textures.
Java and Bedrock do not have a perfect one-to-one texture map. Many names were renamed in the 1.13 flattening, and many Bedrock block-item icons are drawn from the block model rather than a dedicated item texture, so there is nothing to map them to. Textures with a clean match are remapped; the rest pass through with a best-effort path and are counted in the result. The on-page coverage note shows exactly how many block and item textures the map covers.
It converts the parts that have a Java equivalent: textures, metadata, sounds, animations and lang files. Bedrock-only systems such as JSON UI, entity geometry, attachables, particle JSON and render controllers have no Java resource-pack form, so they are reported as not converted. Treat the output as a strong starting point that may need a few manual touch-ups for a complex pack.
Merge several packs into one next, or browse more Minecraft tools:
