ESX vs QBCore: Which FiveM Framework Should You Choose

Same ancestor, two different paths

These are not two independent projects. QBCore is licensed GPL-3.0 with a copyright line naming ESX (Jérémie N'gadi) alongside Joshua Eger, and the LICENSE file shipped in Qbox's qbx_core still opens with the words es_extended, ESX framework for FiveM. Every mainstream FiveM roleplay framework in 2026 traces back to the same GPL codebase. What separated them is structure, not origin.

ESX Legacy is distributed as a bundle. The esx_core repository ships a [core] folder containing 17 separate resources: es_extended itself plus esx_identity, esx_multicharacter, esx_skin, esx_menu_default, esx_menu_list, esx_menu_dialog, esx_context, esx_notify, esx_textui, esx_progressbar, esx_inventory, esx_lib, esx_loadingscreen, esx_chat_theme, skinchanger and cron. Each one is a swappable unit, which is why so many servers run half stock ESX and half community replacements.

QBCore takes the opposite position. qb-core is one resource, version 1.3.0, holding client, server, shared, an html folder and qbcore.sql. Jobs, gangs, vehicles, weapons, items and locations are all shared files inside that resource, and the surrounding qb-inventory, qb-clothing, qb-target family lives in sibling repositories under the same organisation. One core to read, one config.lua to learn, and a tighter coupling when you want to replace a piece.

Side by side

Every value below was read from the repositories and manifests in August 2026, not from forum folklore. Star counts are a weak proxy for adoption and are included only to show relative project scale on GitHub.

Players, money and jobs

This is where the two frameworks stop being interchangeable. On ESX you fetch a player with ESX.GetPlayerFromId(source) and you get an xPlayer object whose methods are lowercase camelCase: addMoney, removeMoney, getAccount, addAccountMoney, setJob, getJob, addInventoryItem, canCarryItem, setMeta and getMeta. Money is modelled as named accounts, and es_extended ships three by default in its shared config: money, bank and black_money, with new characters starting on a 50000 bank balance.

On QBCore you call QBCore.Functions.GetPlayer(source) and the methods are PascalCase under a Functions table: AddMoney, RemoveMoney, SetJob, SetGang, SetMetaData, HasItem. Money types are config-driven rather than fixed, declared as { cash = 500, bank = 5000, crypto = 0 } with a documented note that you can add your own, for example blackmoney, but never remove one once it exists in the database. AddMoney also takes a third argument, a reason string, and fires an economy log plus a QBCore:Server:OnMoneyChange event, which makes money auditing a first-class citizen rather than something you bolt on.

The database tells the same story. ESX keys its users table on the license identifier and spreads identity across real columns: firstname, lastname, dateofbirth, sex, height, plus job and job_grade, with grades defined in a separate job_grades table carrying a salary per grade. QBCore keys its players table on a citizenid and stores charinfo, job, gang, money and metadata as JSON blobs, with job grades declared in Lua under string keys such as ['0']. Neither schema is portable to the other, which is the real reason a framework switch is expensive.

QBCore keeps more character state inside the core than ESX does. Hunger and thirst decay rates, blood types and a reputation system living in player metadata are all in qb-core config and player code, while ESX leaves that to addon resources. Callbacks differ too: ESX exposes RegisterServerCallback, TriggerServerCallback and an await variant, QBCore exposes QBCore.Functions.CreateCallback and TriggerCallback. None of this is better or worse, but it does mean a script written against one core touches nothing the other core understands. If character identity is a big part of your server, Var-MultiChar is an example of a resource built to sit on either one, with the same slot logic wired to esx_skin, qb-clothing, fivem-appearance or illenium-appearance.

Var-BankBanking with personal IBAN accounts, transfers, beneficiaries, 7-day analytics and society accounts through esx_addonaccount or qb-management, with the framework detected at startup.View the script

Inventory and items

Item definitions live in different places, and that single detail explains a lot of porting pain. QBCore declares its item list in a shared file inside the core resource, shared/items.lua, so items ship with the framework and are edited in Lua. ESX exposes ESX.GetItems and ESX.RefreshItems and keeps its catalog in the database, with the repo shipping a dedicated [SQL] folder. Adding an item is a Lua edit on one and a database row on the other.

On the inventory itself, ESX 1.14.0 now ships an esx_inventory resource inside [core], and es_extended has exactly one bridge in its server code: bridge/inventory/oxinventory.lua. In other words, ox_inventory is the only third-party inventory the ESX core integrates with natively, everything else runs through Config.CustomInventory and community glue. QBCore pairs with qb-inventory by default, while Qbox does not treat ox_inventory as optional at all and lists it as a required dependency in its README.

Ecosystem and learning curve

Ecosystem is the argument most people actually mean when they argue about frameworks. ESX is older in practice and its README points readers at a dedicated Cfx.re releases tag, claiming the framework is trusted by over 12,000 communities, a figure that is self-reported by the ESX project and worth treating as marketing rather than a census. The ESX documentation site makes similar claims about 10,000+ active servers. On GitHub the picture is more modest and closer between the two: 450 stars and 797 forks on esx_core against 735 stars and 981 forks on qb-core. Both catalogs are enormous, and neither one is a reason on its own to pick a side.

Learning curve favours QBCore for a first-time server owner, mostly because there is less to read. One core resource, one config.lua covering money, hunger, thirst and permissions, and shared files you can open in a text editor to see every job and item. ESX asks you to understand that the framework is a set of resources and that its data lives partly in SQL. Both install through txAdmin recipes in a few minutes, which is covered in how to make a FiveM server. For the resource layer on top, the shopping lists differ enough to be worth separate reads: best ESX scripts and best QBCore scripts go category by category on each side.

Maintenance activity is one signal you can check yourself instead of taking anyone's word for it. In August 2026, esx_core had been pushed to within the last day, qbx_core within the last three weeks, and the last commit on qb-core main was 17 June 2026. Open an issues tab and a commit history before you commit a year of development to a codebase.

The Qbox case

Qbox is the reason the ESX vs QBCore question is no longer a two-way choice. Started on 27 September 2022 as a QBCore fork, qbx_core is now at version 1.23.0 and its own documentation describes the project as refactored to improve code quality, enhance security, lower performance overhead and integrate with Overextended resources. Its manifest declares oxmysql, ox_lib, OneSync and FiveM server build 10731, and critically it ends with provide 'qb-core', so resources that ask the server for qb-core still resolve. A bridge/qb folder with client, server and shared layers does the translation.

The architectural break is that the global core object is gone. Qbox's conversion guide states plainly that the core object no longer exists and that data is reached through export functions and imported modules instead, with QBCore.Shared lookups replaced by exports.qbx_core equivalents. Job and gang grades become numbers rather than strings. Qbox claims 99 percent compatibility with existing QB scripts, and a December 2024 reply on the Cfx.re framework thread put the practical figure at around 95 percent of QBCore resources working through the bridge. The honest counterweight, from the same thread, is that Qbox has fewer ready-made resources than QBCore, and its GitHub footprint (139 stars) reflects a much smaller project.

Migrating between them

There are two very different migrations hiding behind the same word. QBCore to Qbox is supported and incremental: the bridge keeps old resources running while you replace calls one at a time, and the Qbox docs explicitly say both APIs can be used simultaneously so conversion can happen partially or over time. The documented failure cases are resources that read database tables directly, reach into qb-core files never meant to be used externally, or call core functions in invalid ways. Those break, and they break loudly.

ESX to QBCore, or the reverse, is not a bridge job. The player object, the money model, the job schema and the database layout all differ, so there is no shim that makes an xPlayer answer to Player.Functions.AddMoney. In practice a framework switch means rebuilding your resource layer and writing a data migration for characters, balances, vehicles and inventories. That cost is exactly why buying scripts that already speak both dialects is worth more than it looks on the day of purchase.

How to actually choose

Pick ESX if your developers already read ESX Lua, if you want a core made of parts you can replace individually, or if the specific community resources you have shortlisted are ESX first. Pick QBCore if you want the smallest core to learn, character state like hunger, thirst and reputation handled in the framework rather than in addons, and a first-party resource family under one organisation. Pick Qbox if you are starting fresh in 2026, you are already committed to the ox stack, and you would rather inherit a cleaner codebase than the largest catalog.

Whichever way you go, the framework is a decision you make once and pay for repeatedly. The way to keep that bill low is to avoid resources that hardcode a framework. Var scripts detect ESX, QBCore or standalone at startup and route money, jobs and inventory calls through the detected core, so the same purchase survives a migration. Var-Bank detects the society resource too, esx_addonaccount or qb-management, with no custom table to create, and Var-MultiChar works across four different skin managers for the same reason. Buy for the framework you run today, keep the option on the one you might run next year.

Related: Best ESX scripts · Best QBCore scripts