Why custom potions matter on a real server
A custom potion is one of the quickest ways to make a reward feel authored instead of generic. The same bottle can become a healer’s draught, a dangerous experiment, a ritual catalyst, or a faction-only combat flask. That is why a potion tool matters: the object is small, but it often carries a surprising amount of story, balance, and version-specific syntax.
The builder is useful because it keeps all of those layers on one page. You decide what the bottle does, how it looks, how much of the effect is visible to the player, and which Minecraft syntax branch the final command needs.
What the tool builds
The builder outputs a ready /give command for potion, splash_potion, and lingering_potion. On one page you configure the base potion, extra effects, bottle color, lore, CustomModelData, and the syntax that matches your server version.
Think of a custom potion as four layers
| Layer | Question it answers | Typical examples |
|---|---|---|
| Bottle type | How is the item delivered? | Drinkable, splash, lingering |
| Effect package | What does it do? | Swiftness, debuffs, mixed utility |
| Presentation | How should it feel? | Color, lore, custom name |
| Visual hook | Does it need a custom icon or model? | CustomModelData with a pack-side asset |
Base potion and custom effects
The base potion field accepts vanilla IDs such as swiftness, long_regeneration, or strong_healing. That gives the bottle its built-in foundation, while the custom effects block adds precise tuning for duration, level, particles, icon, and ambient.
potion_contents={
potion:"minecraft:swiftness",
custom_effects:[
{id:"minecraft:night_vision",duration:600,amplifier:0}
],
custom_color:7173375
}
This matters because many good RP potions are not purely vanilla and not purely custom either. They often start from a normal potion identity and then get one or two precise changes that make them fit the server’s fiction.
Version split
Since Minecraft 1.20.5, items use Data Components. In practice that gives custom potions two common formats:
- 1.20.5+ uses square brackets with
potion_contents, plusitem_name,lore, andcustom_model_data. - Before 1.20.5 uses NBT tags such as
Potion,CustomPotionEffects,CustomPotionColor, and the olddisplayblock.
/give @p minecraft:potion[potion_contents={potion:"minecraft:healing"}] 1
/give @p minecraft:potion{Potion:"minecraft:healing"} 1
The builder helps here because most broken potion commands are not bad ideas. They are copied syntax from the wrong era of Minecraft.
Why legacy is trickier
Old potion effects are stored through numeric IDs. The tool hides that translation step: you pick readable effect names like speed and slow_falling, and the builder injects the matching legacy values when they are supported.
Color, lore, and presentation
The same mechanical effect package can feel completely different depending on presentation. Bottle color changes the silhouette in inventory, lore adds narrative context, and CustomModelData lets you connect the potion to a special model or icon in your resource pack.
- A toxic-green concentrate with warning text in the lore.
- A golden holy elixir with a rare visual style.
- A faction-specific potion tied to a unique
CustomModelDataitem model.
How to use the builder calmly
- Choose the syntax that matches your server version.
- Pick the bottle type and a base potion if you need one.
- Add one or more
custom effectswith duration and level. - Decide whether the bottle needs a custom name, lore, and color.
- Only then add
CustomModelDataif the pack actually has a matching visual hook. - Copy the finished
/givecommand into console or a command block.
Practical ideas
- Quest bottles that grant a short utility buff before a scene.
- Faction combat flasks with signature colors and lore.
- Dangerous alchemy shop samples with a dramatic name, heavy debuff, and rare model.
- Lingering bottles for arena or ritual events where the cloud must stay on location.
Common mistakes
- Mixing legacy syntax with component syntax in one command.
- Adding CustomModelData even though the pack has no matching visual asset yet.
- Overloading one bottle with too many effects and losing readability.
- Ignoring lore and color, then wondering why the potion still feels like a generic vanilla bottle.
- Testing only in chat when the command really belongs in a command block.
FAQ
Do I need a resource pack for every custom potion?
No. You only need a pack when the bottle should look different from vanilla.
Can one potion mix a base potion and custom effects?
Yes. That is often the cleanest way to create a recognizable bottle with one or two special twists.
When should I use splash or lingering instead of a normal potion?
When the delivery method is part of the scene: area denial, event clouds, ritual zones, or throwable support items.
Does CustomModelData change the effect?
No. It changes the visual hook. The effect package still comes from the potion data itself.
What if I only want a quick colored bottle with lore?
The builder is still useful. You do not need the most advanced fields to get a bottle that feels authored.