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.
Layered on top is a supplemental rename set of 1,688 texture, 809 sound and 123 language-key mappings covering entity, particle, painting, armor, HUD and sound names. Our block and item map wins on any overlap.
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.
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 3D models and geometry use a system Bedrock does not share, so model conversion is out of scope; 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. Going the other way, Bedrock random texture variations are not rebuilt into Java blockstates, and 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, entity textures (signs, hanging signs, villagers, shulkers, cats, beds, shields, chests, skeletons, the enchant glint), armor layer textures, HUD sprites, 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 (with category, volume and pitch kept), animated textures (Java .mcmeta to and from Bedrock flipbook_textures.json) and language files all convert. Simple block variants with multiple random models also convert to Bedrock texture variations. Some things still have no cross-edition equivalent: custom 3D models and geometry, 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. HUD sprites convert both ways: the 1.20.2-and-newer individual gui/sprites/hud files map to Bedrock textures/ui files, and for older packs the legacy 256x256 icons.png sheet is split into the individual Bedrock UI textures with the exact cut rectangles. Armor model textures are renamed across the editions (chainmail to chain, _layer_1 to _1). Entity textures use a full fixup set: Java signs become flat Bedrock sign files, villager folders move to villager2 with the profession and biome renames, shulker and bed light_gray become silver, cats and skeletons get their Bedrock names, and double chests are handled. Anything that still has no target lands in the not-converted report.
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 detects the source pack_format and rewrites it to the version you choose, adding a wide supported_formats range so the pack loads across many versions. When the target crosses the 1.13 flattening (to or from the legacy 1.8 to 1.12 line) it also renames block and item texture files with the flattening tables, for example planks_oak to oak_planks, gold_sword to golden_sword and record_cat to music_disc_cat, and renames the textures/blocks and textures/items folders to textures/block and textures/item. Every renamed file is listed in the result.
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: block, item and entity textures, armor, HUD sprites (reversed to the modern gui/sprites/hud files), metadata, sounds, animations and lang files. A few things stay out of scope going this way: Bedrock random texture variations are not rebuilt into Java blockstates and models, the legacy Java icons.png HUD sheet cannot be stitched back from split sprites, and Bedrock-only systems such as JSON UI, entity geometry, attachables, particle JSON and render controllers have no Java resource-pack form. All of these are listed in the not-converted report. 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:
