Build a Minecraft Bedrock skin pack locally
This Bedrock skin pack maker combines one or more player skin PNG files with the metadata Minecraft Bedrock uses to identify a classic skin pack. Enter a pack name and creator name, add local skin textures, give each skin a display name, choose its Classic or Slim arm geometry, and download a complete .mcpack.
The browser creates manifest.json, skins.json, texts/en_US.lang, texts/languages.json, and uniquely named PNG files at the archive root. It then writes those files into a ZIP-compatible archive and downloads it with the .mcpack extension. Skin pixels, source filenames, display names, model choices, generated UUIDs, metadata, and the finished archive remain on your device.
The maker does not sign in to Minecraft, publish a Marketplace product, upload files to a server, or guarantee that a particular device can import unofficial packs. It prepares the documented file structure for a local classic-skin workflow. Installation permissions and behavior still depend on the current Bedrock edition, platform, account, and device.
What goes inside the .mcpack
Minecraft needs a manifest to recognize a pack. This tool uses manifest format version 2, creates one header and one skin_pack module, assigns version 1.0.0, and generates two different UUID v4 identifiers every time you build. New UUIDs help prevent a newly created pack from colliding with an unrelated installed pack.
skins.json describes the pack and every included texture. Its serialize_name and localization_name match, as required by the current validation rules. Each skin receives its own localization identifier, unique root-level texture filename, free type, and one of the two documented player geometries.
The language folder contains en_US.lang, which maps the technical localization keys to the pack name, creator, and skin display names. languages.json declares en_US. These files use UTF-8 text. User-entered line breaks and equals signs are removed so a display name cannot accidentally create another language entry.
The actual skin PNG files live at the root of the pack, not in a nested textures directory. The archive also starts directly with manifest.json; it does not place the whole pack inside an extra enclosing folder. That distinction matters because an archive can look tidy in a file manager while still being one directory level too deep for the importer.
Accepted skin files
The maker accepts PNG only, with a maximum input file size of 2 MB per texture. Based on the current Bedrock skin-pack validation reference, player skin textures must be exactly 64×64 or 128×128 pixels. The tool decodes every selected image in the browser and rejects the batch if a file is unreadable or has another size.
A 64×64 file is the standard modern player-skin size. A 128×128 file can carry higher-resolution artwork for Bedrock workflows that accept that size. The pack maker never resizes either format. Smoothly shrinking or enlarging a skin during packaging would change pixels without explaining the loss, so resizing remains a separate task.
Use a complete player texture rather than an avatar portrait, screenshot, cape, elytra, Roblox clothing template, or presentation image. A square image can pass the dimension check and still be the wrong UV layout. Run an unfamiliar 64×64 source through the Minecraft skin checker before packaging it.
The current official validation reference limits a skin pack to 80 skins. The interface displays the current count and stops additional batches that would exceed that maximum. For usability, smaller themed packs are often easier to name, test, update, and share than one archive containing dozens of unrelated designs.
Choose Classic or Slim correctly
Classic uses the documented geometry.humanoid.custom model and has four-pixel-wide arm fronts in a standard 64×64 skin. Slim uses geometry.humanoid.customSlim and has three-pixel-wide arm fronts. Both textures can have the same overall image dimensions, so the package cannot infer the correct model from width and height alone.
Select the model for each skin independently. A pack may contain both Classic and Slim entries. Choosing the wrong geometry can create missing or shifted arm pixels even when the rest of the character looks normal. If the source model is unknown, inspect the UV evidence with the Minecraft skin model detector.
The pack maker does not add custom geometry. Microsoft’s packaging documentation states that custom models are not supported through this skin-pack JSON capability. The two model choices therefore remain intentionally limited to the standard wide-arm and narrow-arm player geometries.
Name the pack and skins
The pack name appears in metadata and localization. Choose a short, recognizable title rather than a filename-like string. The creator name is written to the pack description and the documented .by localization entry. Neither field is an ownership certificate or digital signature.
Every selected file starts with a display name derived from its original filename. You can replace it before downloading. The generated internal identifiers use predictable Skin1, Skin2, and similar keys, while the visible name stays in the language file. This separation allows spaces and readable capitalization in the interface without putting fragile punctuation into technical keys.
The downloaded filename is a lowercase slug based on the pack name. Changing a visible name after packaging requires generating a new archive. The tool does not open or modify an existing .mcpack; keep the original PNG files and recreate the package when an entry changes.
How local ZIP packaging works
An .mcpack is a ZIP-compatible package with a Minecraft-specific extension. This implementation writes standard local file headers, CRC-32 checksums, a central directory, UTF-8 filenames, and an end-of-directory record directly in the browser. Entries are stored without compression. PNG files are already compressed, so applying another general compression layer usually provides little benefit.
Uncompressed storage can make the archive slightly larger than an aggressively compressed ZIP, but it keeps the local encoder small and deterministic. Minecraft receives the same PNG bytes selected by the user, plus the generated JSON and text files. No third-party archive service or upload endpoint participates.
If you want to inspect the result before importing, copy the file, rename the copy from .mcpack to .zip, and open it with an archive utility. You should see manifest.json and skins.json immediately at the root, a texts folder, and one PNG for every listed skin. Do not edit the original archive with a tool that adds an enclosing directory or platform-specific metadata.
Import and troubleshoot responsibly
Microsoft’s current introduction instructs users to open the .mcpack so Minecraft can import it, then choose a classic skin workflow in the Dressing Room. Exact screens and platform permissions can change, so consult the current instructions for your installed edition.
If import fails, first check that the download completed and still ends in .mcpack. Inspect the archive structure, confirm that every texture named by skins.json exists at the root, and verify that the two manifest UUIDs differ. This maker generates those relationships automatically, but another application can alter the archive after download.
If the pack imports but an individual skin looks wrong, the cause is usually the source UV map or model choice rather than the container. Confirm 64×64 or 128×128 dimensions, switch Classic versus Slim for the affected entry, and test transparent outer-layer areas. Rebuild with a new UUID pair after correcting the source.
Unofficial or untrusted skin settings can affect local use. Do not advise another person to weaken device or account protections without explaining the consequence. Server policy, multiplayer visibility, console restrictions, managed devices, and Marketplace rules are outside this pack generator’s control.
Privacy and rights
All selected PNG bytes are read through browser file APIs and remain in memory until the tab is refreshed or closed. Pack assembly uses generated text and local byte arrays. There is no registration, cloud draft, analytics event containing filenames, public gallery, or database record for the package.
Only package skins you created or have permission to redistribute. A technically valid .mcpack does not grant copyright, trademark, publicity, or character rights. Avoid presenting a third-party creator’s work as your own, and do not use a visible creator name to imply an endorsement.
SkinEditor.org is an independent, unofficial tool and is not associated with Mojang or Microsoft. Minecraft and Bedrock names are used descriptively to explain file compatibility. For editing the source artwork, use the Minecraft skin editor. For a simple PNG export rather than a package, keep the editor’s original download.
Frequently asked questions
Does the tool upload my skins?
No. Image checks, metadata generation, UUID creation, ZIP assembly, and download all run in the browser.
Can one pack contain Classic and Slim skins?
Yes. Choose the model separately for every entry.
Are 64×32 legacy skins accepted?
No. This builder follows the current 64×64 or 128×128 player-texture validation rule. Convert a legacy skin before packaging.
Why does each build use new UUIDs?
Manifest UUIDs identify packs and modules. New UUID v4 values reduce conflicts with another generated or installed package.
Can I sell the generated pack?
The tool does not grant commercial rights or Marketplace approval. Rights and distribution eligibility depend on the artwork, platform rules, agreements, and applicable law.