NWC Tester (Simple)
This is not a wallet, not a production monitoring dashboard and not a safe place for broad main-wallet permissions. It is a simple developer test page that helps you see whether an NWC connection responds to a few basic SDK calls.
Start with the shape
NWC Tester (Simple) is almost exactly what its name promises. It is a small browser page, hosted on GitHub Pages by Alby, where you paste a Nostr Wallet Connect connection string and ask the page to run a few basic wallet calls.
The public repository is `getAlby/nwc-tester`. GitHub metadata checked on June 14, 2026 showed a tiny HTML-only repo, created in September 2024, pushed in March 2025, not archived, with GitHub Pages enabled and no release packaging. The repository description calls it a simple website to run and test some NWC functions.
That simplicity is the point. This is not a polished developer console with account management, saved profiles, relay diagnostics, permission editing or a long result history. It is a single page that imports Alby's SDK from a CDN and calls the NWC client directly from the browser.
The right expectation is therefore narrow. Use it when you need to answer a small question: does this NWC secret connect, can it create an invoice, can it return wallet info, and can it list recent transactions? Do not treat it as a complete security audit of an app-wallet relationship.
What the page actually does
The live page shows one text input labeled NWC Secret and three checkboxes: Load Invoice, Load Info and Load Transactions. A Submit button runs the selected calls and prints JSON-like results under the form.
The raw `index.html` is small enough to read in one sitting. It imports `nwc` from `https://esm.sh/@getalby/sdk@3.7.0`. It then creates a new `nwc.NWCClient` with `{ nostrWalletConnectUrl: nwcSecret }`, where `nwcSecret` is the string entered in the form or supplied through the URL query parameter.
For invoice creation, the helper calls `client.makeInvoice` with amount `1000` and memo `Test invoice`. In NWC terms, that is a request to the wallet service to create an invoice. Depending on SDK units and wallet interpretation, the important thing for a tester is not the label but the actual result returned by the wallet service.
For wallet information, it calls `client.getInfo`. For transaction history, it calls `client.listTransactions` with `limit: 5`. It also records `performance.now()` before and after each call and prints the elapsed time, which makes the page a simple latency probe as well as a method probe.
Why it belongs in developer tools
This page belongs in Developer Tools & Libraries because ordinary users should not need it during normal wallet use. A user wants a client, wallet or app. A builder needs a way to check whether a connection string behaves as expected before wiring it into a product.
NWC integrations have several moving pieces: the connection URI, the wallet-service pubkey, the client secret, the relay, encryption, supported methods, permissions, budget limits and response timing. A tiny tester gives a developer a quick way to isolate some of those pieces.
If `getInfo` fails, the connection may be malformed, the relay may be unreachable, the wallet service may be offline, the SDK may be using incompatible assumptions, or the wallet may not support that path. If `makeInvoice` works but `listTransactions` fails, that is a permission or capability clue.
This is useful before you blame your own app. First check the NWC secret in a known simple tester. Then check it in a more detailed tester. Then check your product. A small page can save time because it removes your own UI and backend from the first round of debugging.
The secret is a wallet credential
The biggest thing to understand is that the NWC connection string is not just a harmless test value. It contains or derives the client key material used to sign NWC requests. Whoever has it can ask the wallet service to perform methods allowed by that connection.
That is why the page's convenience must be used carefully. Pasting a main wallet connection with broad permissions into any browser page is a serious action. Even if the page is honest and open source, the browser environment may include extensions, injected scripts, network logs or shared history.
A safe test connection should be disposable. Use a wallet connection made only for testing, with a tiny budget, short expiry and the narrowest method list that matches the test. If you only need `get_info`, do not use a secret that can pay invoices. If you only need invoice creation, do not add outgoing payment permission.
After testing, revoke the connection if the wallet supports revocation. A test should leave the user with less uncertainty, not another long-lived wallet credential floating around in browser history and chat logs.
The query parameter is convenient and sharp
The code reads the `nwc` parameter from the page URL and places it into the form field. It also reads `invoice=1`, `info=1` and `transactions=1` to preselect and automatically process requested calls when the page loads.
That makes the page easy to script for demos. A developer can build a link that preloads a connection and immediately runs a call. For throwaway test wallets, that can be handy. For real wallet secrets, it is a bad habit.
Secrets in URLs can leak through browser history, screenshots, server access logs, analytics, copied links, shared tabs and referrer headers. Even if GitHub Pages does not intentionally collect the secret for this app, the wider web tooling around a URL is not designed for sensitive wallet credentials.
The safe rule is simple: do not put a real NWC connection in the URL. Paste a disposable secret manually, test the method, clear the form, and revoke or rotate the connection afterwards. If an app's documentation tells users to share an NWC tester URL containing a secret, rewrite that documentation.
SDK version matters
The current page imports `@getalby/sdk@3.7.0` from esm.sh. On June 14, 2026, npm reported the latest `@getalby/sdk` version as 8.0.3. That does not make the tester useless, but it means the page is not automatically tracking the newest SDK behavior.
NWC has evolved. The current NIP-47 text emphasizes wallet-service info, supported methods, error codes, notifications and modern encryption choices. Older examples in the ecosystem often used NIP-04 compatibility, while newer paths increasingly expect NIP-44 support.
A simple tester pinned to an older SDK can still be valuable as a baseline, especially if the wallet you are testing supports that SDK's behavior. But a failure may mean version mismatch, not necessarily a broken wallet. Likewise, a success in this tester does not prove your app's newer SDK path will behave identically.
For serious integration work, record the SDK version used in your test notes. If your product uses `@getalby/sdk` 8.x, compare results with a test path that uses the same major version. The tester tells you something real, but only in the context of the code it actually runs.
What get info can reveal
`getInfo` is the least dangerous call and often the best first call. It should tell you what the wallet service says about itself: supported methods, aliases, network details, node color or other wallet-service metadata depending on the wallet implementation.
In NIP-47 terms, wallet information helps the app decide whether a connection can support the intended workflow. If your product needs `make_invoice`, a wallet that only supports `pay_invoice` will not work. If your product needs notifications, you need to know whether that wallet advertises them.
A simple tester that calls `getInfo` gives you a quick capability sanity check. It does not verify every permission or budget, but it can stop you from building on assumptions. Many integration failures come from treating one successful NWC connection as if all NWC wallets behave the same.
The practical sequence is: run `getInfo`, note the returned methods, compare them with your app's intended calls, and only then test invoice or transaction methods. If the info output looks surprising, the answer is usually in the wallet connection settings or wallet-service implementation, not in the tester.
What invoice creation tests
The Load Invoice checkbox tests whether the wallet service will create an invoice through the NWC connection. The page asks the SDK to make a small test invoice and then prints the response.
That checks several layers at once. The connection string must parse. The client must reach the relay and wallet service. The wallet service must accept the signed request. The connection must allow invoice creation. The wallet backend must be able to produce an invoice. The response must come back and decrypt.
If invoice creation succeeds, you have a useful signal that receiving through that connection can work. It does not yet prove that the invoice can be paid from another wallet, that your app will receive settlement notifications, or that the wallet will behave under load.
If invoice creation fails, inspect the exact error. It may be missing permission, unsupported method, offline service, relay trouble, expired or revoked connection, insufficient backend liquidity, encryption mismatch or a wallet-specific validation rule. A good tester narrows the problem, but it does not replace reading the wallet's own logs.
What transaction listing tests
The Load Transactions checkbox calls `listTransactions` with a limit of five. This is more sensitive than `getInfo` because it may expose wallet activity. Even a tiny transaction list can reveal timing, amounts, descriptions, invoice metadata or patterns of use.
That is why transaction permission should be treated separately from payment or invoice permission. A product that only needs to create invoices may not need transaction history. A dashboard might need it, but then it must protect the output and explain why it is asking.
In the tester, transaction listing is useful when debugging settlement state. You can see whether the wallet service knows about recent invoices or payments. You can compare what the wallet returns with what your app expects to display.
Do not run this against a connection whose history you would not want exposed in the browser session. If you need to debug a production issue, create a temporary narrow connection or use the wallet's own admin tooling rather than pasting a broad app secret into a public test page.
The result renderer is not a security boundary
The page prints returned objects by building HTML strings and appending `JSON.stringify` output inside `pre` and `code` tags. That is easy to understand and works for basic results, but it is not a hardened result renderer.
A careful reviewer should notice that wallet-service responses can include text fields. If a malicious or buggy wallet service returns unexpected HTML-like content, a result renderer that writes strings through `innerHTML` deserves scrutiny. Safer developer tools escape text content or assign it through `textContent`.
This does not mean the page is malicious. It means the page is intentionally small and should be treated like a quick test utility, not a defensive browser application. The more hostile your test target, the more you should isolate the browser profile and avoid sensitive secrets.
For normal Alby Hub, trusted-wallet or disposable faucet testing, this may be acceptable. For testing unknown wallet services, fake services or adversarial relays, use a throwaway browser context and a connection with no meaningful funds.
Where it differs from the advanced tester
The simple tester and Super Testnet's advanced tester are related by purpose but not by design. Alby's simple tester gives you one compact form and three SDK-backed actions. Super Testnet's page exposes more separate operations, including permission checks, invoice lookup, payment attempts, balance and transaction filters.
That difference matters when choosing a tool. If you only need to see whether a secret can create an invoice or return info, the simple tester is faster. If you need to inspect what the string can do, test specific payment behavior or explore more NWC methods, the advanced tester is more appropriate.
The simple tester is also closer to the Alby SDK path. It demonstrates how a small browser page can create an `NWCClient` and call methods. The advanced tester is more protocol-exploration oriented and sits near Super Testnet's other NWC learning projects.
Neither page should be treated as a wallet. They are test benches. The difference is how much surface area you want on the bench and how much method-by-method control you need.
How to use it safely
Begin with a test wallet. If possible, use NWC Faucet, a disposable Alby Hub app connection, a tiny Coinos or LNbits test connection, or another wallet profile that contains almost no value. Give it only the methods you plan to test.
Open the simple tester directly. Do not arrive through a link that already contains an NWC secret. Paste the secret into the field. Run `getInfo` first. If that succeeds, run invoice creation. Only run transaction listing if the connection is meant to expose that history.
Record the returned methods, errors and timing. A slow response may point to relay or wallet-service latency. A method error may point to permissions. A timeout may point to a wrong relay or offline service. A good test note says which wallet, which SDK path, which method and which result.
When finished, close the tab and revoke the connection if it was not created purely for repeated tests. If the test revealed a problem, reproduce it with a second tester or your own minimal script before making a product-level decision.
What to check before sharing results
A tester result is often something a developer wants to paste into an issue, Discord thread or support chat. Do that carefully. The returned object may contain invoices, transaction descriptions, preimages, payment hashes, node details, timestamps or other context that identifies a wallet or user workflow.
Before sharing a screenshot or copied result, remove the NWC string, relay secret, full invoice if it is not needed, transaction descriptions and any stable wallet identifier that would let someone correlate the test with a real balance. If the issue is only that `getInfo` fails, the support person usually does not need your full connection string.
Also separate two questions that often get mixed together. One question is whether the connection is valid and the wallet service responds. Another question is whether your product should receive the permissions in that connection. The tester can help with the first question. It cannot answer the second one for your business model, threat model or user consent flow.
If you are using the result to debug a product, write down the path in plain terms: wallet service, relay, method, expected result, actual result, SDK version and whether the connection was disposable. That small note makes the test reproducible without turning the NWC secret into the thing everyone passes around.
If you are using the result to decide whether to support a wallet, repeat it from a clean browser profile and, where possible, from your own minimal script. Browser extensions, stale state and CDN behavior can all affect a test page. Two independent checks are cheap compared with shipping a payment integration that only worked in one tab once.
What it does not prove
A passing simple tester result does not prove that your production app is secure. It does not test your storage model, backend logs, user consent flow, webhook processing, idempotency, payment fulfillment or UI copy.
It also does not prove broad wallet interoperability. It tests one SDK version, one browser environment, one connection and selected methods. Another wallet may use different relays, permissions, encryption compatibility, notification behavior or error handling.
It does not test outgoing payments unless you add another tool. The simple tester does not expose `pay_invoice`, and that is a good thing for a low-friction page. Outgoing payment tests are more dangerous and should be done with explicit low-budget connections.
Treat this page as the first diagnostic, not the final certification. It can tell you whether the NWC path is alive. Your own app still has to prove that it handles money safely.
Where it fits beside Alby tools
Alby has a broader developer stack around NWC: Alby Hub for running a wallet service, the JavaScript SDK for app integrations, the developer guide for NWC concepts, NWC HTTP API for relay-to-HTTP workflows, the CLI for command-line use and sandbox tooling for scenarios.
NWC Tester (Simple) is smaller than all of those. It is the quick browser probe. That makes it useful precisely because it does not require a build step, a local CLI install or a custom script. You can open the page, paste a disposable secret and see a response.
The page also exposes how easy NWC can feel from a developer perspective. One SDK import, one client object, a few method calls. That is the promise of NWC: apps can use Lightning wallet actions without each wallet inventing a completely separate integration surface.
The danger is the same ease. A wallet connection can become just another string in a text field. Good tools keep reminding builders that the string is a permissioned wallet credential. The simple tester is useful when that reminder stays in the foreground.
The practical close
NWC Tester (Simple) earns its place because it is small, readable and direct. It lets a builder verify basic NWC behavior from the browser without creating a new project or wiring a custom script.
Its main strengths are speed and clarity. You can see the exact HTML, the SDK import, the NWC client construction and the three calls. That is excellent for debugging a single connection or teaching the shape of an NWC browser integration.
Its limits are equally clear. It uses an older pinned SDK, accepts secrets from query parameters, prints returned data into the page, and covers only a few methods. It should be used with low-value, narrow-permission test secrets, not broad wallet access.
Use it as a first pulse check. If it passes, keep testing. If it fails, read the error and narrow the layer. Either way, do not let the simplicity of the form make the NWC secret feel less sensitive than it is.
Useful Nostr context
These pages help place the tester beside the wallet, SDK and relay pieces it is probing.
- NIP-47 and Nostr Wallet Connect: Use this when the article mentions NWC secrets, wallet-service permissions or app-to-wallet requests.
- Alby Hub: A practical wallet-service reference point for NWC connections and app permissions.
- Alby JavaScript SDK: The SDK layer behind many Alby browser and app integrations.
- Relays: The network layer that carries Nostr events, including NWC requests and responses.
- NWC HTTP API: Useful when the same NWC flow needs HTTP endpoints or webhooks instead of direct relay sockets.
- NWC Enclaved: A more ambitious wallet-service experiment with NWC, phoenixd and service discovery.
Sources worth opening
Open the live page, raw HTML and repository metadata first, then compare the Alby SDK docs, current NWC docs and NIP-47 so the tester's convenience does not hide the underlying wallet credential risk.
- NWC Tester Simple live page
- NWC Tester Simple GitHub repository
- NWC Tester Simple raw HTML
- NWC Tester Simple README
- NWC Tester Simple repository metadata
- NWC Tester Simple contents API
- NWC Tester Simple commits API
- awesome-nwc raw README
- Nostr Wallet Connect homepage
- NWC SDKs and Tools docs
- NWC best practices docs
- NWC reference overview
- NWC error codes
- NIP-47 Nostr Wallet Connect
- NIP-47 raw specification
- NIP-44 encrypted payloads
- NIP-04 legacy encrypted direct messages
- NIP-01 basic protocol flow
- Alby JavaScript SDK repository
- Alby JavaScript SDK NWC docs
- Alby JavaScript SDK npm registry metadata
- Alby NWC developer guide
- Alby NWC JS SDK guide
- Alby NWC HTTP API code examples
- Alby Hub repository
- Alby CLI repository
- NWC Faucet
- Super Testnet NWC tester
- Super Testnet NWC tester repository
- Bankify repository
