One pack at a time. Java packs are .zip, Bedrock packs are .mcpack (a renamed zip). The tool detects which edition it is. A Minecraft version .jar works too and converts that version's default textures.
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 use a system Bedrock does not share, so block and item model conversion is out of scope; Java core and post shaders (the .fsh and .vsh programs, not PBR material maps), custom fonts, and OptiFine CTM or CIT features have no Bedrock resource-pack equivalent. OptiFine entity models are the exception: a .jem is rebuilt as Bedrock entity geometry with the vanilla bone names, so the mob keeps animating, while the OptiFine animation expressions themselves are left out. 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.
Yes. In the Java to Bedrock output settings, turn on Also generate a behavior pack and the download becomes a .mcaddon holding the converted resource pack next to a companion behavior pack. The behavior pack carries no gameplay, only a manifest that lists the resource pack as a dependency, so enabling it on a world, a Realm or a dedicated server applies the textures along with it. That is the shape add-ons ship in. For a pack you only want in Global Resources, the plain .mcpack is simpler.
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. OptiFine custom entity models (.jem) convert to Bedrock entity geometry. Some things still have no cross-edition equivalent: custom block and item models, Java core and post shaders, custom fonts, and OptiFine CTM or CIT. Those cannot convert, so the tool lists them in an itemized not-converted report with counts instead of dropping them silently.
Custom entity models, yes. Every .jem under optifine/cem is rebuilt as Bedrock entity geometry: each box becomes a cube with the same size, texture offset and inflation, part pivots and rotations carry over, and the bones take Bedrock's vanilla names, so a converted creeper still walks and a converted zombie still swings its arms. The bone-name table was derived by matching the vanilla Java model of each mob against Mojang's Bedrock sample geometry cube for cube, and it covers 123 entities including the baby forms. Parts the JEM leaves out keep their vanilla shape, the same as in OptiFine. Not carried over: OptiFine animation expressions (Bedrock's own animations apply), numbered random variants such as wolf2.jem, block entities like chests and signs, and CTM or CIT, which have no Bedrock form. A texture named in the .jem is copied over the entity's default Bedrock texture.
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.
A Minecraft version .jar, yes. The jar in .minecraft/versions/<version>/ holds that version's whole default resource pack, so dropping it in and picking Java to Bedrock gives you the Java textures on Bedrock. The code inside the jar is skipped without being read. A mod .jar is different: its textures belong to the mod's own items and blocks, which don't exist in Bedrock, and Bedrock can't run Java mods, so the converter tells you that instead of building an empty pack.
No. This tool converts resource packs: textures, sounds, language files and pack metadata. A world is a different job, with chunks, block states and entities to translate, and it needs a dedicated converter. je2be runs in the browser and handles Java to Bedrock and back; Chunker, the open-source converter from the Hive team, covers the same directions and older versions. Convert the world there, then bring the world's resource pack through this tool.
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:
