How Inspekt compares

You have four options for showing a CS2 item on a listing page: build a renderer, use a flat image, embed somebody else's viewer, or embed ours. This page spends as long on the first three as on the fourth. Buyers seldom raise "we could build this ourselves" on a call, so this page answers it in writing.

Two ways to use us

The Inspekt column below is two products, and which one you want changes the comparison. The Render API is a still of the exact item, one GET per listing: an <img> tag, about an afternoon to integrate, and the step up from the flat catalog image most listing pages run today. The embed is the live 3D viewer inside your page: a real integration on your side, and the half a screenshot of your site cannot copy. Hobby, Pro and Enterprise include both, and both take the same Steam inspect link. Render API · Embed parameters · a listing grid running both.

The four options at a glance

Everything in the Inspekt column is checkable before you talk to us. The coverage number comes out of npm run coverage against the catalog and the disk, the plans and quotas are on Pricing, the 7 days and the uptime number are in Terms section 9 and the SLA, and the whole surface is in the docs with a sandbox that needs no account.

Building it yourself

Below is what we had to do, in the order they bit us, so you can price the project instead of estimating "a 3D viewer" at three weeks.

1. Getting the assets out of the game, and keeping them out

CS2 ships its models, textures and materials inside Source 2 packages. To read them you need a Valve Resource Format decompiler, a KTX2 encoder, and a CS2 depot on disk, which is roughly 35 GB pulled through steamcmd and re-pulled every time Valve patches. Then you need a parser for Valve's KV3 material format, including the binary blob form, because a meaningful share of the numbers you need are in there.

Running those tools is the smaller problem. The hard part is that the pipeline is a join: item definitions, paint kits, the icon listing, and the files on disk all have to line up, and when they do not, the failure is silent and flattering. Our own catalog builder joined a weapon and a kit with a literal NUL byte in two places and a plain space in a third, so the extractor missed eight skins, among them an M4A1-S Emerald Marbleized and all four Gamma Doppler phases, and no check caught it. Separately, 94 gloves were reported as an extraction gap when every glove manifest was already on disk and only the index was stale. Both bugs made the coverage number look like a rendering problem, which is the flattering explanation, and in both cases that explanation was wrong.

Some of what you want cannot be extracted at all, and has to be rebuilt by hand.

2. Porting the finish compositor exactly

A CS2 finish is a small program: a paint style, a base texture, a pattern, a wear mask and a set of per-kit constants, composited at load time. There are ten weapon finish styles to port, plus the glove cloth composite, and they are not variations on one shader. One of them is used by four items in the entire game and you still have to write it, or four items render wrong forever.

The errors in this stage are quiet. A colour that is subtly wrong looks like a lighting problem. A customer who puts your render next to the game sees that class of bug, which rules out "close enough".

Then comes the grade. Matching the game's tone and highlights is a job of its own, and every change to it invalidates every thumbnail and every cached render you have. We check every render against Valve's official renders.

3. Wear and pattern seed

Each kit remaps float onto its own range, and the compositor consumes it differently per style, so the same float on two skins is not the same wear. Pattern seed selects the crop and rotation of the pattern texture, which is the entire basis of the Case Hardened blue gem, Marble Fade ranks and the Doppler phases. Those phases carry distinct kits, so they are catalog entries in their own right.

Get either wrong and every trader on your site can see it, and traders are the people who care most.

4. Stickers and charms

Five sticker slots, over 11,000 stickers, each with its own scratch wear, plus the holo, foil and glitter treatments. Placement is where we went wrong. Steam's human-readable description line lists sticker names in slot order and carries no slot number, so using the position in that list as the slot shifts every sticker left past an empty slot. We shipped that bug. A lone sticker in slot 4 imported as slot 1, and it was wrong on 8 of the 9 sticker-bearing items in our test inventory.

The correct source is the XOR-masked item preview block, the same structure an inspect link encodes, which carries real slot numbers, per-sticker wear, and the free placement a player has been able to set since 6 February 2024: offset and rotation. Decoding it is a protobuf you write by hand against no published schema.

Then the models disagree with the data. Only four weapon materials in the game define five sticker positions, while CS2 lets a player apply five stickers to anything. A fifth sticker on a four-position weapon renders at position 0, the grip. The slot numbers map straight through with no offset, the certificate's rotation of 90 degrees is what stands the sticker upright, and the overflow lands on the grip.

Charms hang from a keychain anchor and, in the game, run a softbody drape. Ours holds a static pose instead, which is one of the limits listed below.

5. Storing and shipping it

Full coverage is about 20 GB of transcoded textures, backdrop video, models and thumbnails, content-hashed and immutable, before you count a render cache. Then a second-order cost:

• Thumbnails are downstream of the grade. Change the grade and every pre-baked thumbnail is stale. That is a full re-bake of one image per combination, plus a cache purge on every box, every time the grade moves.

6. The standing cost of every new case

A project estimate skips this part, because it is a standing cost. Valve ships cases without warning. Each one adds items and paint kits and occasionally needs a technique you have not written, so someone has to have the game installed, the pipeline working and the afternoon free, forever. We publish 7 days for that and it is in the Terms as a commitment.

The number you publish has to be derived from the catalog and the disk. Ours read 2,274 in one document and 95.2% in another before anyone made it a tool. Both were wrong, in the direction that made us look better.

When building it is the right call

Three cases:

• The renderer is your product. If the 3D view is the reason people choose your site over the next one, keep your differentiator in-house.
• You need it inside your own perimeter. The asset tree and the renderer live only on our infrastructure, so if your requirement is that no traffic leaves your network, look elsewhere.
• You already have the pipeline. If someone on your team already extracts CS2 assets for another reason, the marginal cost of the renderer is well below what this page describes, and the estimate above does not apply to you.

Static screenshots and Valve's item icons

The cheapest option, and the one most listing pages should probably still be using for most of their traffic. Valve ships an icon for every item, it is free, it loads instantly, it works in every browser, and it keeps working regardless of any vendor's fortunes.

An icon cannot show this item. The icon for a Case Hardened is the same icon for the one with the blue play side and the one that is mostly grey, and those two items differ by four figures in price. A screenshot library has the same limit at a larger scale: one picture per skin, shared by every float, seed and sticker combination. Once your listing page has to answer "what does the one I am buying actually look like", a flat catalog image is a picture of the category.

The middle path is our Render API, which is a still image too. It takes the inspect link of the specific item and returns a webp you can cache forever, because the URL's identity is a hash of the config. It is one <img> tag, and it displays on any device or browser. If flat images are working for you and the only problem is that they are generic, the Render API is a smaller change than the embed and probably the one to start with.

The existing third-party viewers

Third-party viewers exist and they are good. The arrangement we propose, a marketplace embedding a third-party 3D viewer instead of building one, is one the market already uses, and we make no claim to have invented it.

Our specifics come from a hands-on teardown we ran ourselves: we drove a real browser against a live competitor in July 2026 and re-read it in September, independent of their marketing and their source. Their catalog was 2,126 skins plus knives and gloves, with a custom WebGPU engine, their own compiled asset formats decoded in WebAssembly, and a server-assisted shader cache per device tier. It is a serious piece of engineering and their renderer is at least as good as ours.

Four differences we would stake a claim on, with the caveat that a competitor can close any of them and our teardown may already be stale:

• Steam inventory import. We parse an account's public inventory into wear, seed, stickers, StatTrak and name tag, addressable by Steam ID, vanity name or profile URL. The viewer we tore down had no equivalent. See Inventory API.
• A permissive device gate. Their WebGPU check false-negatived real hardware during our teardown, including an RTX adapter, which is lost traffic for whoever embedded them. Ours fails to a clean 2D card rather than a hard block, and browsing works without WebGPU.
• No bot interstitial in front of the widget. Their site sits behind a challenge that fires on automated sessions. A widget on your listing page is something your monitoring, your screenshot tooling and your own crawlers will hit.
• Published prices. Ours are on Pricing with the quotas that go with them. The commercial terms of the arrangement we are modelling ourselves on are not public, which changes how long it takes you to decide.

If you are already integrated with a viewer and your users are not complaining, the case for moving is narrow. Integration cost is real, your team learned their API, and a small gain in highlight accuracy will not pay for a migration.

What we do not do

Each item below was checked against the running service. If one of them is a requirement, it is better for both of us that you find it here.

• The 3D embed needs WebGPU. A visitor on Safari or Firefox gets a clean 2D fallback card reading "The live 3D view needs WebGPU". In practice that is most iPhone traffic today. The Render API covers those visitors, but only with a still image.
• A StatTrak knife shows its kill count differently. The game etches its readout into the blade; the counter box is the gun module, a separate asset outside our current set. Everything else an inspect link carries (float, pattern seed, stickers with their free placement, the charm, the counter and the name tag) renders in both the embed and /api/still, and a still says in an x-cs2-notes header when it could not draw something.
• The charm does not swing. The game runs a softbody drape on it; ours rests in a static pose.
• Stickers sit flat. Without normal blending or peeled edges, a sticker lies flush against the surface rather than deforming it or lifting at a corner.
• Most scenes have a still backdrop. We ship 15 environments. Four have a recorded video backdrop. The other 11 have a cubemap backdrop that, at the narrow inspect lens, is magnified enough to read soft. The item itself is unaffected.
• The highlights are a little shorter than the game's. On some finishes a specular highlight ends sooner than it does in the game. It is an open lighting job.
• Everything runs on our infrastructure, under our brand. You embed our origin. Hobby and Pro are paid plans with a 10-day free trial that needs no card, and a key serves once the account starts the trial or subscribes. The sandbox and the demo grid run the product without an account.
• No native mobile SDK. The embed is a web view.
• The embed's cold-load budget is unmeasured. We set a target of under 2.5 seconds to the first correct pixel and have not measured it end to end on a mid-range machine. Treat it as an intention.
• One person. One person handles support, directly and without a backup rota. The response targets in Terms section 8 apply to the first reply only, and a fix carries no target.

Who should not buy this

Six situations where the answer is no. Better to say so now than in month three:

• You need infrastructure-grade availability. If a blank widget on your listing pages is an incident with a postmortem, a 99.5% monthly uptime commitment is too low for you. Read the SLA first.
• Your traffic is mostly iOS and you need 3D on it. WebGPU reaches only some of that audience today, and a still image falls short of what you are asking for.
• You need it inside your own network. Everything we ship runs on our infrastructure and is licensed as a service only, with no exceptions.
• You are buying pricing or float data. Wrong product.
• You need a procurement process. We offer a short set of published documents and one signature; a process built around a SOC 2 report, a security questionnaire or a negotiated MSA won't find a match here.
• Your current viewer works. Keep it. Come back when it stops working, or when you want the inventory import.

Check it yourself

Everything above is either measurable from outside or written into a document you can read without an account. The fastest way to disagree with this page is to put a real inspect link into the sandbox and look at the result next to the item in-game.

If you are unsure whether it fits, email hello@inspekt.gg with what you are building. If it is a poor fit, we will say so.