How to Allocate More RAM to Minecraft (Java Client)

You allocate RAM to the Java client by editing one JVM argument, -Xmx, inside your launcher: the official launcher hides it under Installations → Edit → More Options → JVM Arguments, where the default line reads -Xmx2G, and third-party launchers like Modrinth, Prism, and CurseForge hand you a memory slider instead. Raise that number, but don't max it out. Give Minecraft up to about half your total RAM, no more than the game actually uses, and leave the rest for the operating system, because an oversized heap makes garbage-collection pauses longer and stutter worse, not better.

Where the RAM setting lives in each launcher

The official Minecraft launcher buries the setting in a per-installation menu. Open the Installations tab, hover the profile you want to change, click the three-dots menu (⋮) on the right, and hit Edit. Expand More Options and you'll see a JVM Arguments field. The default string starts with -Xmx2G, where that 2G is the two gigabytes Minecraft is allowed to use. Change it to -Xmx4G or whatever number you've settled on and leave the rest of the line alone. If you're hunting for a slider here, stop looking; the official launcher dropped its memory slider years ago, so the JVM argument is the only lever you get.

The third-party launchers are friendlier about it and give you a slider instead:

• Modrinth App: Settings → Java and Memory → the Allocated memory slider. This one is measured in MB.
• Prism Launcher: Settings → Java → Maximum memory allocation for the global default, or per-instance via Edit Instance → Settings → Java, where you tick the Memory override box first.
• CurseForge: Settings → Minecraft → the Allocated Memory slider, which defaults to 4096 MB.

One thing that trips people up: the sliders are in megabytes and the JVM argument is in gigabytes (G) or megabytes (M). They line up cleanly once you know the math. -Xmx6G is exactly the same as -Xmx6144M, because 6 × 1024 = 6144. So a slider sitting at 6144 MB and a JVM argument of -Xmx6G allocate identical amounts. If you ever mix the two up, that's usually why.

How much to actually give it

Allocate up to about half your physical RAM, but never more than the game will actually touch, and always leave at least 3-4GB free for Windows or macOS and whatever browser you've got open. Your machine isn't just running Minecraft. The OS, Discord, a browser with fifteen tabs, and a music app all want memory too, and if you hand it all to Java there's nothing left for them.

Here's how that shakes out by machine:

• 8GB PC: give it 3-4GB. That leaves enough for the system and a browser without choking.
• 16GB: 6-8GB is the sweet spot for almost everyone.
• 32GB: 8-10GB, and honestly you rarely need more even for big modpacks.

Match the number to what you're actually playing, too. Plain vanilla at a normal render distance is perfectly happy on 2-4GB. The default -Xmx2G is often fine, and 4GB covers you with headroom to spare. A heavy modpack running 150+ mods is the case that actually wants 6-8GB, because every mod loads its own assets, registries, and world data into the heap. If you're on an older or weaker box and leaning on lighter modded content, our rundown of the best modded servers for low-end PCs covers packs that stay playable without demanding a huge allocation in the first place.

The one hard limit: never set -Xmx above what you physically have installed. Telling Java it can use 16GB on an 8GB machine doesn't give you more memory, it just guarantees a crash or a swap-thrashing mess the moment it tries to claim what isn't there.

Why maxing it out backfires

More RAM feels like it should always be better, and that instinct is wrong here. Two things go sideways when you crank -Xmx to the ceiling.

First, garbage collection. Java constantly allocates and discards objects as you play, and periodically the garbage collector sweeps through the heap to clean up what's no longer needed. A bigger heap means there's more memory to walk when a full stop-the-world collection fires, and when it does, everything freezes for the length of that pause. So a 12GB heap can produce a longer, more noticeable hitch than a 6GB one. That's the counterintuitive part: more RAM can make your stutter worse, not better, because you feel it as a periodic freeze every time a big collection runs.

Second, you starve the OS. Allocate nearly all your physical RAM to Minecraft and the system has nothing left, so it starts paging memory out to disk. That paging is called swap, and reading or writing it is orders of magnitude slower than real RAM, so a session that was smooth turns choppy the second the OS begins juggling pages. Headroom beats a huge number every single time.

Worth separating this from server-side problems, because they look similar from your chair. A local GC hitch is your own client freezing; if the whole server rubber-bands and everyone lags at once, that's a different animal with a different fix. See fixing lag spikes on a multiplayer server. Adjusting your client -Xmx does nothing for that.

-Xmx vs -Xms, and the 64-bit Java requirement

Two arguments look almost identical and do different jobs. -Xmx is the maximum heap — the ceiling Java is allowed to grow to, and the one that actually matters. -Xms is the starting (minimum) heap, the amount Java grabs the instant it launches. Set -Xmx to your target and leave -Xms modest or unset. There's a temptation to pin both high (-Xms8G -Xmx8G) so Java claims everything up front, but on a normal client that only pre-commits all that RAM the moment you launch, feeding the OS-starvation problem above for no real gain.

Then there's the 64-bit gotcha. A 32-bit Java install caps out around 1.5GB no matter what number you type, and it won't fail politely. It refuses to launch with "Could not reserve enough space for object heap" or "Error occurred during initialization of VM". If you set -Xmx4G and get one of those strings, you're almost certainly on 32-bit Java. Modern installs bundle 64-bit Java so most people never hit this, but it's the error to recognize if a big value suddenly bricks your startup.

Check whether RAM is even your problem

Before you touch any of this, find out if RAM is actually the bottleneck. Press F3 in-game and look at the top-right corner. The Mem: line shows a percentage of heap in use plus the allocated total — something like Mem: 47% 1878/4096MB. That percentage is the tell.

If Minecraft is only using 40-50% of what it already has and your FPS is still in the gutter, RAM is not your problem, and adding more won't move a thing. Low framerate on a half-empty heap is a GPU or CPU limit, and the fix lives elsewhere. Start with why your FPS tanks on servers specifically. If the game feels fine locally but everything is delayed and slow to respond, that's the network, and no amount of heap touches it; lowering your ping is the lever there, not -Xmx.

Don't confuse RAM with VRAM, either. Shaders eat video memory on your GPU, not the Java heap, so if a shaderpack is stuttering, bumping -Xmx accomplishes nothing. That's a graphics-card limit wearing a costume.

After you change it, verify it took

Fully restart the game and the launcher after editing the argument. The JVM reads -Xmx once at startup, so a running instance keeps its old value until you actually relaunch. Closing to the title screen isn't enough. Once you're back in, press F3 and check that the allocated total on the Mem: line moved. If it went from /2048MB to /6144MB, the new argument loaded and you're done.

One last trap: the change is per-profile and per-instance. Editing "Latest release" in the official launcher does nothing to a separate modded installation, and a Prism instance override only touches that one instance. If you run both vanilla and a modpack, you have to set each one independently. People forget this constantly, wonder why their heavy pack still runs out of memory, and it's because they only edited the vanilla profile.

FAQ

Does allocating more RAM increase FPS?

No. Once you have enough, framerate is bound by your GPU and CPU, not the heap. Use the F3 Mem: line to check before you blame RAM: if you're sitting at 50% usage and still lagging, adding more does absolutely nothing. RAM only helps when you're genuinely near 100% and the game is starving.

Why won't Minecraft start after I raised the RAM?

You either set -Xmx above your physical RAM, or you're running 32-bit Java. The giveaway is the exact crash text "Could not reserve enough space for object heap" in the launcher log. Lower the number so it fits what you actually have, and if it still won't launch, install a 64-bit Java runtime, since 32-bit can't allocate past roughly 1.5GB.

How much RAM does a modpack with shaders need?

Roughly 6-8GB of heap for a 150-mod pack, which is the modded case where a bigger -Xmx genuinely pays off. But shaders are a separate resource entirely — they consume VRAM on your graphics card, not the Java heap, so bumping -Xmx won't fix shader stutter. If a shaderpack is choppy, that's a GPU limit, and you'd drop the shader quality or resolution instead.

Is the client RAM the same as a server's RAM?

No. They're two separate -Xmx settings on two separate processes. Allocating memory to your client does nothing for a server you host, even on the same PC. The server reads its own -Xmx from its start command or start script, so you'd edit that file to give the server more, completely independent of whatever your client is set to.