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 is about the first three as much as the fourth, because the objection nobody raises on a call is "we could build this ourselves" and it deserves a real answer.

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

This is the honest column, so it goes first and it gets the most room. Nothing below is meant to scare you off. It is the list of things we had to do, in the order they bite, so you can price the project properly 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.

The pipeline is not the hard part. The hard part is that it 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. The result was eight skins that the extractor never saw and that nothing complained about, including an M4A1-S Emerald Marbleized and all four Gamma Doppler phases. 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 both were wrong.

Some of what you want is not extractable at all. The game's post-processing shaders sit in a shader package at a version the public decompiler refuses, so anything you need from them you re-derive by measurement rather than by reading.

2. Porting the finish compositor exactly

A CS2 finish is not a texture. It 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. Our catalog scan counts SolidColor 136, Hydrographic 330, SprayPaint 243, Anodized 20, Anodized Multicoloured 392, Anodized Airbrushed 62, CustomPaintJob 387, Patina 163, Gunsmith 304, and Titanium 4. Titanium 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. Ours included decoding the manifest paint colours as sRGB when they are linear, which makes every colour subtly wrong in a way that looks like a lighting problem. That class of bug is why the phrase "close enough" does not survive contact with a customer who puts your render next to the game.

Then the grade. Matching the game means the tone curve with the per-scene constants out of the map manifests, per-scene exposure calibration, and the bloom chain: four quarter-resolution levels, a four-tap bright pass with a linear soft knee, a stand-in for the game's separable gaussian, tent combines, and the border-black behaviour of the game's samplers. We shipped a hard clamp at the white point for months and did not notice. It measured as 84.8% of a Printstream's slide fully clipped to white, against 0.0% on the reference we compared with, while the mean luminance matched. Mean luminance matching is exactly why nobody notices. The fix was a swept roll-off constant, and it invalidated every thumbnail and every cached render we had.

3. Wear and pattern seed

Float is not a slider from 0 to 1. Each kit remaps it 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, not a post-processing tint.

Here is a number for how exact this has to be: on our own regression suite, a change of pattern seed on one item measures 33.0 dB and a change of wear measures 35.0 dB, where the pass threshold for "nothing moved" is 50 dB. Seeds and wear are not a subtle effect. If you get them wrong, every trader on your site can see it, and they 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. The placement data is the interesting part. Steam's human-readable description line lists sticker names in slot order, not by 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 can set since May 2024: offset, rotation and scale. 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. We know that because we checked one item against an in-game screenshot: 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. One verified item was enough only because slots run 0 to 4 and a weapon has four positions or five, so there is exactly one remap the rule can ever make.

Charms hang from a keychain anchor and, in the game, run a softbody drape. Ours does not, and that is in What we do not do 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 two second-order costs that surprise people:

• Thumbnails are downstream of the grade. Change the tone curve 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.
• Reference renders are per machine. We keep a golden-image suite so that a lighting change has to prove it did not move anything else. Run on a different GPU and a different operating system, 19 of the 23 cases we had at the time passed outright. The four that failed were the brightest-backdrop scenes, drifting about 5 levels out of 255 in the bright tail: visually identical, numerically not. So the references are a per-machine baseline and each one records the adapter it was baked on, because loosening the tolerance enough to absorb that drift would blind exactly the cases the suite exists to catch.

6. The standing cost of every new case

This is the part that does not appear in a project estimate, because it is not a project. Every case Valve ships adds items and paint kits, occasionally needs a technique you have not written, and arrives without warning. 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, not a target.

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

When building it is the right call

Three cases, and they are real:

• The renderer is your product. If the 3D view is the reason people choose your site over the next one, do not rent your differentiator.
• You need it inside your own perimeter. We do not license the asset tree or offer on-prem, so if your requirement is that nothing leaves your network, we are not an option at any price.
• You already have the pipeline. If someone on your team already extracts CS2 assets for another reason, the marginal cost of the renderer is much lower than it is for us to describe, 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, it never breaks, and no vendor can take it away from you. Any comparison page that pretends otherwise is selling something.

What it cannot do is 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, not per float, seed and sticker combination. The moment your listing page has to answer "what does the one I am buying actually look like", a flat catalog image stops being an image of the product and becomes an image of the category.

The honest 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. No WebGPU on the visitor's device, no JavaScript, no iframe. 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

They exist, they are good, and the arrangement we are proposing is one the market has already done: a marketplace embeds a third-party 3D viewer rather than building one. We are not claiming to have invented this shape.

What we can say concretely comes from a hands-on teardown we ran ourselves, driving a real browser against a live competitor in July 2026 with a re-read in September. Not from their marketing, and not from 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 actually 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 nothing 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 at all.
• 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 is a real difference in how long it takes you to decide.

And the honest counterweight: 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 "ours is a bit more accurate in the highlights" is not a migration budget.

What we do not do

Checked against the running service, not against an old roadmap. If one of these 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", not the 3D view. In practice that is most iPhone traffic today. The Render API covers those visitors with a still image, and that is the answer, but it is a still image.
• A StatTrak knife has no counter. The game etches its readout into the blade; the counter box is the gun module, and we have no asset for the etched one. Everything else an inspect link carries — float, pattern seed, stickers with their free placement, the charm, the counter, 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. Sticker normal blending and peeled edges are not implemented, so a sticker does not deform the surface under it or lift at a corner.
• Most scenes are uncalibrated. We ship 15 environments. Four have a per-scene exposure calibration and a recorded video backdrop. The other 11 take a neutral default and a cubemap backdrop that, at the narrow inspect lens, is magnified enough to read soft. The item itself is unaffected; the background is what suffers.
• The highlight tail is still short. Our items are lit by a pre-filtered capture rather than the game's light probe volume, which shows up as a slightly compressed specular tail against a reference render. This is a known open lighting job, not a finished one.
• No price or market data. We render items. Float rank, market history and pricing are somebody else's product and we are not going to bolt on a worse version.
• No self-hosting, no on-prem, no white label. You embed our origin, and our wordmark is on the free and starter tiers.
• No native mobile SDK. The embed is a web view.
• One box. A single self-hosted origin on a residential connection, no automatic failover, no CDN. One hardware fault, power cut or ISP outage takes the whole thing down. We commit to 99.5% monthly uptime with that in mind and describe the infrastructure in full in SLA section 3 rather than behind a nicer number.
• No continuous integration. The golden suite needs a GPU and the asset tree, so it runs on the box that has both, by hand, before a render change ships. It has caught a real regression, which is why we keep it, but nothing forces it to run.
• 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, not a number.
• One person. There is no support rota, no second pair of hands, and no pretending otherwise. Response targets are in Terms section 8 and they are targets for a first reply, not for a fix.

Who should not buy this

Six situations where the answer is no, and where we would rather 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, one residential line and no failover is not the dependency you want. Read the SLA first; it is written to let you make that call.
• Your traffic is mostly iOS and you need 3D on it. WebGPU is not there yet for most of that audience, and a still image is not what you are asking for.
• You need it inside your own network. No on-prem, no asset licence, no exceptions.
• You are buying pricing or float data. Wrong product.
• You need a procurement process. No SOC 2 report, no security questionnaire function, no negotiated MSA. There is a short set of published documents and one signature behind them.
• Your current viewer works. Genuinely. Come back when it does not, or when you want the inventory import, and we will still be here.

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.

Still not sure whether it fits? Email hello@inspekt.gg with what you are building. A straight "no, that is not what this is" is a perfectly normal answer.