New to JSON UI? This walks through one full round trip: draw a screen, export it, see it in Minecraft.
Minecraft Bedrock draws its interface from .json files inside a resource
pack. A resource pack can replace those files, which is how custom menus,
HUDs and scoreboards are made. JsonForge is a visual editor for them: you draw,
it writes the JSON.
Two things are worth knowing before you start:
- Sizes are in UI units, not screen pixels. A new project is a 384x216 screen, which is roughly what the game gives you at default GUI scale. The canvas draws each unit 3x larger so it is comfortable to work with (Settings > Canvas Scale).
- A resource pack can only restyle what the game already draws. It cannot invent new values. Live text has to come from somewhere the game feeds: a form the script opens, or the scoreboard.
- Pick a template on the welcome screen - Blank, Dialog Form, Form Buttons List, Scoreboard Sidebar or HUD Overlay.
- Add elements from the Toolbox (they land inside the selected element).
- Move and resize on the canvas, or type exact numbers in Properties >
Transform. Arrow keys nudge by one unit,
Shift+arrow by a grid step. - Drop a texture from the Textures panel onto a panel, image or button -
or click the swatch in a texture property to open the picker. The bundled
ore-UI preset styles are all there, and you can upload your own PNG
(plus its nine-slice
.json, if it has one). - Properties > Layout > Layer decides what is drawn on top.
- Need everything smaller? Select the container and use Scale with children at the top of the Properties panel.
File > Export Addon gives you three targets:
| Screen Type | What it makes | Where it works |
|---|---|---|
| Form | server_form.json + a behavior pack script that opens it with an item |
Your own world (servers do not run your behavior pack) |
| HUD overlay | hud_screen.json, resource pack only |
Anywhere, including servers via Global Resources |
| Scoreboard | scoreboards.json, replaces the vanilla sidebar |
Anywhere, keeps live names and scores |
Leave Layout on Fit to screen: sizes are written as percentages, so the
result covers the same share of the screen as in the editor.
You get a .mcaddon when a behavior pack is involved and a .mcpack when the
export is resource pack only. Double-click the file, then enable the pack in
the world (or under Settings > Global Resources for servers) and move it to the
top of the list.
A form covers the whole screen, not the vanilla dialog box, and gets a close button in the top right corner of its outermost panel. You do not draw that one - it is added on export.
The desktop app lists the worlds it finds on this machine under Test World.
Install to World builds the same pack and writes it into that world's own
resource_packs and behavior_packs folders, adding it to the world's pack
lists - no file to save and import by hand.
Restart the game afterwards: JSON UI files and pack textures are read when the world loads, so a running game keeps showing the previous build.
Form buttons are not fixed to the drawing. The buttons you draw under one
parent are read as a table - their centres give the columns and rows, their
bounding box gives the area - and exported as a single grid over the
form_buttons collection.
The script then decides how many there are. Draw four in a 2x2 and send three
from form.button(...): the first three places are filled and the fourth is
never built. Send one and you get one, in the top left place.
Two things follow from this:
- Every button is drawn from the first one you drew. A grid paints all its cells the same, so per-button textures and fonts are not kept - style the first button and the rest follow.
- The drawing sets the capacity. A 2x2 holds four; a fifth button sent from the script has nowhere to go. Draw the largest table you need.
Draw a single button and none of this applies - it stays exactly where it is, bound to its own index.
The form title does double duty: it routes to the screen and it is text you
can show. The generated main.js sends both:
const SCREENS = {
"hub_form": {
title: "Hub Form",
buttons: [ ... ],
},
}
const form = new ActionFormData().title(name + screen.title);server_form.json looks for the screen name inside the title, and a label
wired to form_title subtracts it back out - so the player reads Hub Form
and never sees the flag. Change the title: line to change what is drawn; the
flag in front of it has to stay.
Static labels are drawn exactly as designed. To show real values, wire a label to the game in Properties > Scoreboard:
| Live Value | Comes from |
|---|---|
form_title |
What the script passed to form.title(...) on a form screen |
objective_title |
The display name of the objective on the sidebar |
player_name |
Row N of the sidebar, name column |
player_score |
Row N of the sidebar, score column |
Row Index picks which row, so each value can sit anywhere in your design
instead of being stacked in a list.
Feed them with plain commands:
/scoreboard objectives add match dummy "00:20"
/scoreboard objectives setdisplay sidebar match
/scoreboard players set "GS" match 0
/scoreboard players set "BJK" match 0
Rows are ordered by score, not by the order you set them.
Form buttons work the same way: give a button an action in Properties >
Action (message, command, another screen, or a scoreboard operation), and
put {score:objective} in its text to print a live score.
- Is the pack enabled in the world, and at the top of the list? Minecraft applies the highest pack that owns a file.
- Turn on Settings > Creator > Content Log and rejoin. It names the file and the property it choked on.
- Restart the game after re-exporting - UI files are cached hard.
- For a Form export, both packs have to be on and Beta APIs enabled, otherwise the script never runs and you get the vanilla form.
Use .jfproject (File > Save). It is one file holding the element tree,
the bindings and every texture, so it opens anywhere with nothing missing.