ox_target vs qb-target: Compatibility and Migration

Choose the target your required scripts support natively. Keep qb-target on a stable QB stack when a switch solves no demonstrated problem. Choose ox_target when your selected resources use its API and documented framework integrations. Neither choice makes a script compatible by itself, and renaming an export is not a migration.

This comparison reviews official documentation and source files on 1 November 2026. It is not a runtime benchmark. The examples demonstrate client-side registration; they do not implement a secure shop, inventory or job. Both projects provide public source code; check each repository's license before redistribution.

Quick comparison

Decision	ox_target	qb-target
Required library	ox_lib	PolyZone
Framework boundary	Standalone targeting; documented extra integrations for ox_core, ESX and qbx_core	QBCore is optional; framework-dependent checks need the appropriate integration
Box registration	addBoxZone with a parameters table	AddBoxZone with separate geometry and option arguments
Permission-related options	groups, items, canInteract	job, gang, citizenid, item, canInteract
Migration shortcut	Partial qtarget compatibility; not a blanket qb-target replacement guarantee	Existing native qb-target integrations can remain unchanged

What the target actually does

A target resource lets players select interactions on entities, models or zones. The resource performing the action still owns its business logic: opening a garage, buying an item or going on duty. Compare that action's requirements separately from the eye icon or menu design.

Start with your framework and dependency inventory. For each must-have script, record the target name, supported release, config switch and any editable integration file. A product's QBCore badge does not establish ox_target support. On Qbox, the core bridge and a target integration are separate checks; the Qbox installation notes explain that wider stack.

Native APIs: the same simple test interaction

These independently written client examples register a two-metre box around sample coordinates. Use one on a development resource after its dependencies start. Move the box to an accessible test location. Clicking only prints a message to the client console; no money, inventory or permissions are changed.

qb-target

exports['qb-target']:AddBoxZone('comparison_demo', vector3(100.0, 200.0, 30.0), 2.0, 2.0, {
    name = 'comparison_demo',
    heading = 0,
    debugPoly = true,
    minZ = 29.0,
    maxZ = 31.0
}, {
    options = {
        {
            label = 'Test interaction',
            icon = 'fas fa-circle',
            action = function()
                print('comparison_demo selected')
            end
        }
    },
    distance = 2.0
})

ox_target

local zoneId = exports.ox_target:addBoxZone({
    name = 'comparison_demo',
    coords = vector3(100.0, 200.0, 30.0),
    size = vector3(2.0, 2.0, 2.0),
    rotation = 0,
    debug = true,
    options = {
        {
            name = 'comparison_demo_option',
            label = 'Test interaction',
            icon = 'fas fa-circle',
            distance = 2.0,
            onSelect = function()
                print('comparison_demo selected')
            end
        }
    }
})

-- Remove this demo zone when it is no longer needed:
-- exports.ox_target:removeZone(zoneId)

Do not apply a global search-and-replace to production code. Zone shape and height, option names, callback arguments and entity identifiers need review. In ox_target, addEntity takes network IDs; addLocalEntity takes local handles. Inspect each actual call instead of assuming an integer means the same thing in both APIs.

Compatibility is more than showing an option

ox_target's groups and items depend on framework integration. Do not assume a QBCore job condition becomes a working group check because the menu opens. Its qtarget compatibility layer provides a subset of another API; the manifest provides qtarget, not a universal promise for every resource calling qb-target.

Client visibility is not authorization. A player can attempt to trigger a server event without selecting its target option. The server must independently validate the player's role, position, required items and permitted transaction. Hiding a button with canInteract cannot secure a reward or purchase.

A migration checklist with a rollback point

Back up the resource files and configuration. List native target calls, config selectors, dependencies, job/item checks and cleanup handlers.
Install the chosen target and required libraries on a copy. Start dependencies before target consumers; keep changes out of the live resource directory.
Adapt one interaction, then test allowed and denied users, distance limits, zone height, action arguments and resource restart. Check for duplicate options.
Test real workflows separately: a garage retrieves the intended vehicle; a job action verifies duty and grade; a shop checks payment and inventory on the server.
Remove or disable the old registration only after the replacement passes. Keep the previous files and config ready to restore. Repeat the audit for every consumer.

Performance, maintenance and the buying decision

There is no comparable benchmark in this review. Measure your own client resource time and frame behaviour with the same map, interactions and player actions. Separate idle targeting, an open option list and the action's own work. A faster-looking UI does not establish a lower server cost.

For new interaction and menu resources, inspect the exact target API and version before buying. That category includes different interaction styles; it is not a promise that every listing supports both systems. Prefer an existing documented selector over maintaining a private adapter. For a stable server, avoiding an unnecessary conversion is a valid technical and commercial decision.

Frequently asked questions

Can I replace qb-target with ox_target without editing scripts?

Only when every consumer already supports the chosen integration or you have verified an appropriate bridge. The partial qtarget layer alone does not establish that result.

Is ox_target only for Qbox?

No. It is standalone targeting with additional documented framework integrations. Framework-specific conditions still need the matching support.

Should I run both?

Use an isolated test to identify any need for coexistence. Overlapping registrations can confuse users and make failures harder to diagnose. Choose one supported path for each interaction and verify keybinds and menus.

The FiveM comparison hub connects this target decision with the framework, inventory and other dependencies around it.

ox_target vs qb-target: Choose by Your Scripts and Migration Cost