Load app
- Allow the host your app runs on — the emulator only acts there.
- Load the app. The injected objects appear after the page loads.
- Open “Test” to check it against the standard.
New here? — what this tool does and where things are.
Allowed hosts
The emulator only becomes active on these hosts. All other pages are left untouched — no header is rewritten and no script is injected there.
While you work
Writes every emulator call to the page console, including the ones the inspector filters out.
Keyboard reference
| ←↑→↓ | Navigation |
| Enter | OK / Select |
| Backspace | Back |
| RG YB | Colour keys |
| Space | Play |
| P | Pause |
| S | Stop |
| 0–9 | Digits |
| Ctrl⇧H | Toggle inspector |
The default mapping. It can be changed under Device → Keys.
RedOrbit HbbTV Emulator & Testsuite v2.0 · emulates ETSI TS 102 796
UserAgent
The number after HbbTV/ is the version of the ETSI specification,
not the HbbTV version number — HbbTV/1.4.1 is HbbTV 2.0.1.
Takes effect on navigator only after a reload.
Document
Broadcast
Keys
Browser protections
Both switches disable protections of the real browser — on the allowed hosts only. Removing CSP/HSTS is on by default (§4.4), setting CORS headers is off. Turn both off for hosts you did not build yourself.
Target
Scenarios
Record one walk through your app with the remote-control keys, give it a name, and replay it after every change. The run then follows a path you chose instead of searching for one — it checks the same things either way, and it reaches what a search cannot: numeric keys, text fields, and screens behind them. The first replay becomes the baseline; every later one is compared against it. “New baseline” drops that baseline so the next run records a fresh one — use it after a change that was meant to alter the screens. A scenario only ever covers its own path.
Heads-up: recording and replaying both reload this site with its cookies, localStorage, sessionStorage, IndexedDB and caches cleared — without that a recorded path does not start from the same place twice. Anything you are signed in to on this site will be signed out, other subdomains included.
What you type is part of the recording: it is stored, shown in the report and included when you export a scenario. Password fields are the exception — their value is never captured, and the replay says so instead of guessing.
No scenarios yet.
Test run
The run explores the app by pressing remote-control keys — colour keys, arrows, OK and BACK — and by triggering the stimuli only an emulator can produce: stream events, a channel change, a parental block. Every screen it reaches is identified by a signature, so the same screen is not explored twice. It reloads the page to get back to a screen, so the app is restarted many times during a run. The check is deterministic: two runs of the same app produce the same findings, with or without an API key.
Heads-up: each reload clears this site’s cookies, localStorage, sessionStorage, IndexedDB and caches — without that an app that keeps state on the client cannot be explored past its first screen. Anything you are signed in to on this site will be signed out, other subdomains included.
There is nothing to configure here. Depth and limits are fixed so that two runs of the same app stay comparable; the report lists them under “Bounds”.
No run yet.
The path
Findings
Emulator limits
Different here than on a television — caused by the emulator, not by the app. These are not defects of your app.
Not reached
A test tool that only shows what it found is misleading. This is what the run did not cover.
Report
The key belongs to you and is stored in chrome.storage.local —
not in storage.sync, so it does not travel to other devices
through your Google account. It never reaches the tested page. Without a key
the emulator makes no outgoing request at all.
Saving asks Chrome for permission to contact
api.anthropic.com and then checks the key against it — through
the model list, which costs no tokens. A key that is rejected is not stored,
and the permission is handed back. If the check cannot run at all (no
network), the key is stored and marked as unverified: that is a third state,
not a yes and not a no.
Optional. Add an API key below to have a model summarise and prioritise the report. The check itself runs without one and finds exactly the same things.
The default is the strongest model, and the reason is not quality of prose: the prompt carries text from the tested app by construction, and the summary has to keep following its rules — do not re-classify, do not invent a citation — even when that text is phrased as an instruction. The difference for a run of this size is about two cents. Prices are from the list of the date shown below and are an estimate, not a bill.
What this is
This extension makes a Chrome tab behave like the browser of an HbbTV television. Your app finds what a TV would give it: the broadcast and application objects, the remote-control keys, a TV User-Agent and the right Content-Type.
- Develop without a television on your desk.
- Watch what your app calls, with the Inspector overlay.
- Check it against ETSI TS 102 796, the HbbTV standard.
It follows the HbbTV profile, not more: what a TV does not offer, this emulator does not offer either. A few things a TV has are stubs here — the search manager, media synchronisation, and three key codes whose values are not published; the report says so when you hit one. It is a development tool, not a certification test.
Three steps to start
-
Allow the host Under App → Allowed hosts, or with the “Allow” button next to the address. The emulator acts only on allowed hosts; everywhere else Chrome stays untouched.
-
Load the app The TV objects are there when the page loads. After changing a switch, reload the page — an app reads the objects once.
-
Use the keyboard as the remote Arrows, Enter for OK, Backspace for Back, R G Y B for the colour keys. Turn on the Inspector to see what your app calls (it keeps the last 500 events).
The three working tabs
- App
- What you are working on right now: load the app, allow its host, and the switches you flip while you work — Inspector, the 720p frame that shows the TV’s 1280 × 720 coordinate system, and the console debug mode.
- Device
- The television you emulate. Which HbbTV version it claims (User-Agent), whether your document is served as XHTML, whether the app is started from a broadcast channel or on its own, which channel is tuned, which key codes the remote sends — and whether the browser’s own protections stay on. Each group shows its current value in the header; open it to change something.
- Test
- Check the app against the standard and get a report. See the next card.
Testing, two ways
Both ways press remote-control keys on your app and write the same kind of report. The tab starts with the target: which page is tested and whether the emulator is active there.
- Scenarios
- You walk through the app once with the keys, the recording gets a name, and you replay it after every change. The first replay becomes the baseline; later runs are compared with it. This is the way for things a search cannot reach: number keys, text fields, a specific video.
- Exploration
- The emulator presses the keys itself and visits as many screens as it can find. Nothing to set up. It will not reach everything — the report lists what it did not reach.
Heads-up: every run reloads the site with its cookies and storage cleared, so the app starts from the same place each time. Anything you are signed in to on that site will be signed out, other subdomains included. What the run cannot clear — HttpOnly cookies, a session on the server — the report names as “reset incomplete”.
Reading the report
- Findings
- Where your app does something a television would not accept. Most name the place in the standard; where no passage covers the case, the finding says so. “Replay” presses the same keys again so you can watch it happen.
- Emulator limits
- Where the emulator behaves differently from a TV. These are not defects of your app.
- Not reached
- What the run did not cover — so you know what the report cannot say.
- AI summary
- Optional. With your own Anthropic API key, a model rephrases and prioritises the findings. It never adds or removes one. The summary becomes part of the report and of every download you make after it.
- Download
- HTML to send on (self-contained), JSON for a build pipeline, Markdown for a ticket. An exploration report comes back when you reopen the panel; a scenario run and the AI summary do not — download what you want to keep.
Good to know
- Some switches work at once — Inspector, 720p frame, key mapping. The ones that change what the page is served (UserAgent, document type, protections) need a reload: an app reads the objects once.
- Browser protections (Device, last group): removing CSP and HSTS from allowed hosts is on from the start, and the yellow banner at the top says so. The CORS switch is off. Turn both off for hosts you did not build yourself.
- Two requests can leave your machine, both to api.anthropic.com and both only on your click: checking the key when you save it, and the summary when you press “Summarise report”. Nothing else. “Preview what gets sent” shows the summary request first.
- Ctrl + Shift + H toggles the Inspector inside the page.
- Allow user scripts once in chrome://extensions → Details. Without it the page still gets the TV User-Agent header, but navigator.userAgent stays Chrome’s — the Device tab warns you.
- Every (i) in the panel explains the setting next to it, with the source in the standard where there is one.
What each setting does
In the order of the Device tab. Each (i) in the panel explains the setting itself; this is about why you would change it.
UserAgent
- Send UserAgent · Profile · Text
- Every request to an allowed host carries a television’s User-Agent instead of Chrome’s, and with user scripts allowed the app sees it in navigator.userAgent too. The profile picks the HbbTV version the TV claims, 1.5 to 2.0.5; the number in the string is the ETSI spec version (HbbTV/1.4.1 is HbbTV 2.0.1). Only the string changes — the emulated objects stay the same. Change it to see whether your app still starts on an old device, or reads the version correctly. Edit the text to imitate a vendor string.
Document
- Rewrite Content-Type · XHTML / HTML
- HbbTV servers send the start page as application/vnd.hbbtv.xhtml+xml, which Chrome would download instead of showing. The emulator rewrites it. XHTML is the normal case and strict — a markup error shows an error page, as it would on the TV. HTML is forgiving. Switch to HTML only to get a broken page running; switch back to find the error.
- Application type
- A TV starts red-button apps from the broadcast signal (broadcast-related), and those may use the channel API. An app that runs without a channel (broadcast-independent) gets a SecurityError from getChannelConfig(), bindToCurrentChannel(), prevChannel() and nextChannel(), and currentChannel is null. Switch to independent to check that your app starts cleanly without a channel and handles those errors instead of staying blank.
Broadcast
- Start channel
- The channel the emulated TV is tuned to when your app starts — what currentChannel returns and what bindToCurrentChannel() shows. The list imitates a German DVB line-up; the numbers are made up. Change it when your app loads content by channel, or to test setChannel() to a channel other than the first.
- Switch delay
- Time between CONNECTING and PRESENTING on a channel change, 300 ms by default; a real TV takes longer. Set 0 to test state handling quickly, set it high to see whether your app shows the in-between state and does not assume PRESENTING too early.
Keys
- Key profile
- The numeric values behind VK_RED, VK_ENTER and the rest. The standard says the constants must exist, not what they are. cea-2014a is the common set; pc-fallback is the one used by the mitxp test suite (colour keys on F5–F8). Switch profiles to catch numbers hard-coded in your app: if it works with both, it uses the constants. Reload the page after switching.
- Key mapping
- Which PC key acts as which remote key. This is not in any standard, it is convenience; only your changes are stored. Change it when the defaults (R G Y B for the colour keys) clash with your keyboard or habits.
Browser protections
- Remove CSP / HSTS
- Strips Content-Security-Policy and Strict-Transport-Security from responses of allowed hosts. On by default: a server policy would otherwise block scripts or force https where the app runs on http. Turn it off for hosts you did not build, or to check that your app also runs with its real policy.
- Set CORS headers
- Adds Access-Control-Allow-Origin: * to responses of allowed hosts. Off by default; only needed to test streaming from another domain.
While you work (App tab)
- Inspector overlay
- A panel inside the page: calls, keys, stream events, media and warnings, with the place in the standard where there is one. It collects from page load; the switch only shows it. Ctrl + Shift + H does the same.
- Console errors
- Takes what the app writes with console.error() and console.warn() into the inspector, under “Warnings” — so you do not have to keep the browser console open beside it. The output there is unchanged. On by default. What the browser itself writes (net::ERR_…, 404, CORS) does not pass through console; those are reported separately as failed requests, failed resources and CSP violations. Turn this off when measuring an app that inspects console.error itself — the wrapper is visible to the page, a television has none.
- 720p frame
- Puts the page into a 1280 × 720 frame with a safe-area marking — the coordinate system HbbTV apps are built for. Side effect: position: fixed aligns to the frame, not the window. If rendering looks wrong, turn this off first.
- Debug mode
- Writes every emulator call to the page console, including the ones the Inspector filters out. For the cases where you need the raw sequence.