Skip to content

Testeur WebSocket en ligne (client ws/wss)

Binaire affiché en HEX, vraies trames binaires envoyées depuis HEX/Base64, codes de fermeture expliqués et liste de vérifications : testez ws:// ou wss:// dans le navigateur. Les messages vont droit à votre serveur, pas au nôtre.

Fonctionne dans le navigateur Gratuit
Votre navigateur envoie les messages directement au serveur que vous indiquez — ils ne passent pas par les serveurs de go-tools.
Remplir : (service d'écho tiers : disponibilité non garantie, et vos messages sont transmis à ce tiers)
Non connecté

Les messages s'affichent ici. Aucune connexion WebSocket n'est ouverte tant que vous n'avez pas cliqué sur Se connecter.

Envoi périodique (heartbeat applicatif)
ms

Ceci envoie un message texte ordinaire à intervalle régulier. Ce n'est pas une trame ping au niveau du protocole — les pages web ne peuvent ni envoyer ni voir les trames ping/pong. Désactivé par défaut, car un serveur qui ne s'y attend pas peut fermer la connexion.

Connexion, messages texte et binaires, codes de fermeture, échecs de handshake, délai de connexion, handshake Socket.IO, heartbeat, reconnexion et un flot de 10 000 messages sont testés de bout en bout face à un serveur WebSocket local ; le comportement des navigateurs décrit sur cette page a été mesuré dans Chromium, Firefox et WebKit en octobre 2026. — Équipe Go Tools · 13 oct. 2026

Conçu et vérifié par l'équipe d'ingénierie Go Tools.

Testeur WebSocket : réponses rapides

Cette page HTTPS peut-elle se connecter à ws://localhost ?

Oui dans Chrome, après avoir autorisé l'accès au réseau local Cela dépend du navigateur (en octobre 2026). À partir de la version 147, Chrome demande d'abord si la page peut accéder aux appareils de votre réseau local ; une fois que vous avez choisi Autoriser, ws://localhost et ws:// vers une adresse IP du réseau local se connectent. Firefox se connecte directement à localhost mais bloque les adresses du réseau local. Safari bloque ws:// depuis les pages HTTPS.

Pourquoi une connexion échouée n'affiche-t-elle que 1006 ?

Le navigateur masque la cause Quand le handshake échoue, les navigateurs sont tenus de ne transmettre à la page qu'une erreur et le code de fermeture 1006 — jamais le statut HTTP ni la cause. Appuyez sur F12 : la console de Chrome et d'Edge affiche le code de statut renvoyé par le serveur.

Puis-je ajouter un en-tête Authorization ?

Les navigateurs ne peuvent pas définir d'en-têtes Non. L'API WebSocket du navigateur ne permet pas de définir des en-têtes de requête. Placez le jeton dans un paramètre d'URL, un sous-protocole ou un cookie — selon ce que votre serveur accepte.

Le heartbeat est-il une trame ping ?

C'est un message ordinaire Non. Les pages web ne peuvent ni envoyer ni voir les trames ping/pong du protocole ; le navigateur répond lui-même aux pings du serveur. L'envoi périodique de cet outil est un message texte ordinaire envoyé à intervalle régulier, et il est désactivé par défaut.

Pourquoi ne puis-je pas me connecter à un serveur Socket.IO ?

Utilisez le préréglage Socket.IO Socket.IO n'est pas du WebSocket brut. Choisissez le préréglage Socket.IO : il se connecte à /socket.io/?EIO=4&transport=websocket, répond 40 au paquet d'ouverture et répond à chaque ping 2 par un pong 3 (Socket.IO v3/v4).

Qu'est-ce qu'un testeur WebSocket en ligne ?

Un testeur WebSocket est un client que l'on pointe vers un serveur WebSocket pour voir s'il accepte la connexion et ce qu'il renvoie. Vous saisissez une adresse ws:// ou wss://, vous vous connectez, vous envoyez des messages texte ou binaires et vous lisez les réponses — le moyen le plus rapide de vérifier un endpoint backend, un proxy inverse ou un appareil qui parle WebSocket sans écrire de code client.

Ce testeur fonctionne dans votre navigateur : la connexion va directement de votre navigateur au serveur que vous indiquez, et les messages ne passent pas par les serveurs de go-tools. Cela implique aussi les limites du navigateur. Il ne peut pas ajouter d'en-têtes de requête personnalisés, il ne peut pas envoyer de trames ping au niveau du protocole et, quand un handshake échoue, le navigateur ne communique à la page que le code de fermeture 1006, pas la raison.

Ce qu'il apporte par rapport à une simple console de navigateur : les messages binaires affichés en HEX (ou en Base64) et envoyés depuis HEX ou Base64 sous forme de vraies trames binaires, le JSON mis en forme automatiquement, les codes de fermeture expliqués, une liste de vérifications quand une connexion échoue, un avertissement avant la connexion quand le navigateur risque de bloquer l'adresse, et un journal qui reste fluide à environ 2 000 messages par seconde (mesuré).

09:30:01.204 · Connecting to ws://localhost:8080/ws
09:30:01.219 · Connected · subprotocol: chat
09:30:02.517 → TXT 17 B {"type":"hello"}
09:30:02.531 ← TXT 25 B {"type":"hello","ok":true}
09:30:03.002 → BIN 4 B 48 69 00 FF
09:30:03.010 ← BIN 4 B 48 69 00 FF
09:30:09.880 · Closed · code 4001: application-defined code

Fonctionnalités du testeur WebSocket

Localhost et réseau local : conseils propres à chaque navigateur avant de vous connecter

Avant la connexion, l'outil vérifie l'adresse : un ws:// non chiffré vers un nom de domaine depuis cette page HTTPS sera bloqué, il le signale donc et propose wss://. Pour localhost et les adresses IP du réseau local, il indique que Chrome demandera l'accès au réseau local, et en quoi Firefox et Safari diffèrent (en octobre 2026).

Messages binaires en HEX, vrais envois binaires

Les messages binaires reçus s'affichent en HEX, 16 octets par ligne, ou en Base64. Saisissez des octets sous la forme 48 69 00 FF, 0x48,0x69 ou en Base64 : ils partent en message binaire. Les caractères invalides et les nombres impairs de chiffres sont signalés avec leur position, et l'aperçu des octets montre exactement ce qui sera envoyé.

Des codes de fermeture et des échecs exploitables

Chaque fermeture affiche le code, le texte de la raison et si le handshake de fermeture s'est terminé, avec la signification des codes standard 1000–1015 et une note pour les codes applicatifs 4000–4999. Un échec avant l'ouverture de la connexion produit une liste de vérifications plutôt qu'une supposition.

Journal rapide avec recherche et export

Les messages sont dessinés une fois par image, si bien que la page reste fluide à environ 2 000 messages par seconde lors de nos tests. Chaque entrée indique le sens, l'horodatage à la milliseconde, le type et la taille en octets. Filtrez par sens, recherchez, mettez l'affichage en pause, conservez les N dernières entrées, copiez ou exportez en texte.

Sous-protocoles, délai d'attente, préréglage Socket.IO

Demandez un ou plusieurs sous-protocoles (séparés par des virgules) et voyez si le serveur en a confirmé un. Un délai de connexion met fin aux handshakes auxquels le serveur ne répond jamais. Le préréglage Socket.IO effectue le handshake Engine.IO v4 et répond aux pings à votre place.

Heartbeat et reconnexion, sur demande

L'envoi périodique répète le message de votre choix à intervalle régulier, et la reconnexion automatique réessaie avec un délai exponentiel après une coupure inattendue. Les deux sont désactivés par défaut, et l'outil n'envoie jamais rien que vous n'ayez demandé.

Exemples de test WebSocket : localhost, binaire, codes de fermeture, Socket.IO

Tester un serveur de développement local

ws://localhost:8080/ws
Connecté
→ TXT 17 B {"type":"hello"}
← TXT 25 B {"type":"hello","ok":true}

Dans Chrome 147 et versions ultérieures, le navigateur demande d'abord s'il faut autoriser l'accès à votre réseau local ; choisissez Autoriser. Firefox se connecte directement à localhost ; Safari bloque ws:// depuis cette page HTTPS (en octobre 2026).

Envoyer un message binaire depuis du HEX

48 69 00 FF
→ BIN 4 B 48 69 00 FF

En mode HEX, l'outil envoie un message binaire contenant ces quatre octets, et non le texte 48 69 00 FF. En Base64, SGkA/w== envoie les mêmes quatre octets.

Lire une fermeture côté serveur

Le serveur ferme avec le code 4001, raison « token expired »
Fermé · code 4001 : code défini par l'application · fermeture propre
Raison : token expired

Les codes 4000–4999 sont définis par l'application : cherchez 4001 dans la documentation du serveur. Les codes 1000–1015 sont standard et sont expliqués dans le journal.

Se connecter à un serveur Socket.IO

Protocole : Socket.IO v3/v4, adresse ws://localhost:3000
Connexion à ws://localhost:3000/socket.io/?EIO=4&transport=websocket
← 0{"sid":"…","pingInterval":25000,…}
→ 40
← 40{"sid":"…"}

Le préréglage complète le chemin et la query Socket.IO, répond 40 pour rejoindre le namespace par défaut et répond à chaque ping 2 par 3. Envoyez les événements sous la forme 42["event","data"].

Comment tester un WebSocket en ligne

  1. 1

    Saisir l'adresse du serveur

    Tapez ou collez une adresse ws:// ou wss:// ; http:// et https:// sont traités comme ws:// et wss://. Lisez la note sous l'adresse : elle prévient quand le navigateur risque de la bloquer.

  2. 2

    Ajouter des sous-protocoles si le serveur en exige

    Certains serveurs exigent un sous-protocole, par exemple mqtt. Saisissez-en un ou plusieurs, séparés par des virgules. Après la connexion, le journal indique celui que le serveur a confirmé.

  3. 3

    Se connecter

    Cliquez sur Se connecter. Pour localhost ou une adresse du réseau local dans Chrome, choisissez Autoriser quand l'accès au réseau local vous est demandé. Si la connexion échoue, suivez la liste de vérifications qui s'affiche.

  4. 4

    Envoyer et lire des messages

    Choisissez Texte, HEX ou Base64, vérifiez l'aperçu et appuyez sur Ctrl+Entrée. Le JSON reçu est mis en forme et le binaire s'affiche en HEX ; basculez le binaire en Base64 dans la barre d'outils du journal.

  5. 5

    Filtrer, puis copier ou exporter

    Filtrez par sens ou recherchez dans le journal, mettez l'affichage en pause pendant un flot de messages, puis copiez ou exportez le journal en texte avec horodatages, sens et tailles en octets.

Erreurs de connexion WebSocket courantes

ws:// vers un nom de domaine depuis une page HTTPS

Les navigateurs bloquent un ws:// non chiffré vers un nom de domaine depuis une page chargée en HTTPS (contenu mixte). Chrome et Firefox refusent immédiatement avec une SecurityError. Utilisez wss:// ; pour un serveur du réseau local dans Chrome, écrivez son adresse IP (l'accès au réseau local doit être autorisé).

✗ Incorrect 
ws://api.example.com/ws
✓ Correct 
wss://api.example.com/ws

Du HEX saisi en mode texte

En mode texte, 48 69 est envoyé comme les caractères 4, 8, espace, 6, 9. Passez en HEX pour envoyer les octets 0x48 0x69 dans un message binaire.

✗ Incorrect 
Mode texte : 48 69 → TXT 5 B
✓ Correct 
Mode HEX : 48 69 → BIN 2 B

URL Socket.IO utilisée comme WebSocket brut

Un serveur Socket.IO refuse un WebSocket brut sur son chemin racine et, sans réponse à son handshake et à ses pings, il ferme la connexion. Utilisez le préréglage Socket.IO.

✗ Incorrect 
ws://localhost:3000
✓ Correct 
ws://localhost:3000/socket.io/?EIO=4&transport=websocket

Jeton dans un en-tête de requête

Les navigateurs ne peuvent pas envoyer d'en-tête Authorization avec un handshake WebSocket. Si votre serveur le permet, transmettez plutôt le jeton dans un paramètre d'URL ou un sous-protocole.

✗ Incorrect 
Authorization: Bearer eyJ…
✓ Correct 
wss://api.example.com/ws?token=eyJ…

Quand un testeur WebSocket en ligne est utile

Vérifier un endpoint backend
Confirmez qu'une nouvelle route WebSocket répond, examinez les premiers messages qu'elle envoie et testez sa réaction à des entrées malformées — avant même que le frontend existe.
Déboguer un proxy inverse
Derrière Nginx ou une passerelle, voyez si l'upgrade passe et combien de temps une connexion inactive survit.
IoT et protocoles binaires
Les appareils et brokers qui parlent binaire sur WebSocket se lisent en HEX, et vous pouvez leur envoyer des octets exacts depuis HEX ou Base64.
Reproduire des codes de fermeture
Voyez le code de fermeture et la raison que le serveur envoie réellement, par exemple quand un jeton expire ou qu'un client est limité en débit.
Affichage à haut débit de messages
Regardez un serveur pousser environ 2 000 messages par seconde (mesuré) sans figer la page, avec des compteurs de messages et d'octets.

Comment fonctionnent les connexions WebSocket dans le navigateur

Le handshake d'ouverture
Un WebSocket commence par une requête HTTP avec Upgrade: websocket. Le navigateur construit lui-même les en-têtes de requête — Origin, Sec-WebSocket-Key, Sec-WebSocket-Version: 13 et Sec-WebSocket-Protocol à partir de la liste des sous-protocoles — et la page ne peut pas en ajouter d'autres. Le serveur répond 101 Switching Protocols, puis les deux côtés échangent des messages.
Messages texte et binaires
send() avec une chaîne envoie un message texte encodé en UTF-8 ; send() avec des octets envoie un message binaire. Les pages reçoivent des messages entiers, jamais des trames, des fragments ni des masques. Cet outil règle binaryType sur arraybuffer afin que les messages binaires arrivent dans l'ordre et puissent s'afficher en HEX.
Pourquoi les erreurs n'ont aucun détail
La norme WebSocket interdit aux navigateurs d'indiquer aux scripts pourquoi une connexion a échoué — échec DNS, port refusé, erreur de certificat ou HTTP 401 se ressemblent tous — afin qu'une page ne puisse pas sonder votre réseau local. Les pages voient un événement error et le code de fermeture 1006 (Firefox signale les erreurs de certificat avec le code 1015).
Contenu mixte et accès au réseau local
Une page HTTPS ne peut pas ouvrir un ws:// non chiffré vers un hôte public. Depuis Chrome 147, WebSocket relève aussi de l'accès au réseau local (Local Network Access) : joindre localhost ou une IP privée depuis une page publique nécessite votre autorisation. Firefox exempte les adresses de bouclage ; Safari non (en octobre 2026).
Codes de fermeture
Un client ne peut fermer qu'avec 1000 ou 3000–4999, et la raison ne peut pas dépasser 123 octets en UTF-8. 1005 (pas de code de statut) et 1006 (fermeture anormale) ne circulent jamais sur le réseau ; c'est le navigateur qui les signale. 1015 n'est signalé pour les échecs TLS que par certains navigateurs.

Conseils pour tester un WebSocket

Utilisez wss:// en dehors de votre machine
Le wss:// chiffré avec un certificat reconnu comme fiable atteint les serveurs publics depuis cette page dans tous les navigateurs et protège les jetons présents dans l'URL ; pour localhost ou les adresses du réseau local, Chrome demande tout de même d'abord l'autorisation d'accès au réseau local. Réservez le ws:// non chiffré à localhost.
Consultez la console quand le handshake échoue
La page ne voit que 1006. Chrome et Edge affichent le statut HTTP dans la console, ce qui pointe généralement droit vers un problème d'authentification, de chemin ou de proxy.
Autorisez l'Origin côté serveur
Les navigateurs envoient toujours Origin. Si votre serveur le vérifie, autorisez https://go-tools.org pendant vos tests ; les en-têtes CORS ne s'appliquent pas à WebSocket.
Laissez le serveur envoyer les pings
Pour maintenir les connexions inactives à travers les proxys, faites envoyer des trames ping par le serveur ; le navigateur y répond automatiquement. N'utilisez l'envoi périodique que si votre protocole attend un message applicatif.
Gardez les jetons hors des journaux partagés
Les adresses contiennent souvent des jetons. L'outil ne garde l'adresse et les messages qu'en mémoire, mais les journaux exportés et les captures d'écran les incluent — retirez les secrets avant de partager.

FAQ du testeur WebSocket

Puis-je tester ws://localhost ou un serveur du réseau local depuis cette page HTTPS ?
Cela dépend du navigateur (en octobre 2026). À partir de la version 147, Chrome traite les connexions WebSocket vers votre ordinateur ou votre réseau local comme un accès au réseau local : la première fois, il demande s'il faut autoriser ce site, et une fois que vous avez choisi Autoriser, ws://localhost, ws://127.0.0.1 et ws:// vers une adresse IP du réseau local comme 192.168.1.10 se connectent. Dans Chrome, le serveur du réseau local doit être écrit sous forme d'adresse IP ; un simple nom d'hôte (autre que .local) est bloqué même s'il résout vers votre réseau. Firefox se connecte directement à localhost mais bloque ws:// vers les adresses du réseau local. Safari bloque ws:// vers localhost et le réseau local depuis les pages HTTPS. wss:// n'est pas concerné par la règle du contenu mixte : les serveurs publics fonctionnent depuis cette page dans tous les navigateurs tant que le certificat est reconnu comme fiable ; pour localhost ou les adresses du réseau local, Chrome demande là aussi d'abord l'autorisation d'accès au réseau local.
Pourquoi ne puis-je pas me connecter à ws://example.com depuis cette page ?
Cette page est servie en HTTPS, et les navigateurs bloquent une connexion ws:// non chiffrée vers un hôte public depuis une page HTTPS (contenu mixte). Chrome et Firefox refusent immédiatement avec une SecurityError, que l'outil signale. Utilisez l'adresse wss:// du serveur. Les sites publics servis en http simple ne sont pas soumis à cette règle, mais dans les versions récentes de Chrome ils ne peuvent pas du tout joindre localhost ni votre réseau local.
La connexion a échoué avec le code 1006 — que s'est-il passé ?
1006 signifie seulement que la connexion s'est terminée sans handshake de fermeture. Quand un handshake échoue, la norme WebSocket impose au navigateur de cacher la cause à la page — un 401, un 404, un port refusé, une erreur de certificat et un Origin rejeté se ressemblent tous (Firefox signale les erreurs de certificat avec le code 1015) — donc aucun testeur web qui se connecte directement depuis le navigateur ne peut l'afficher. Appuyez sur F12 et ouvrez la console : Chrome et Edge affichent le statut HTTP renvoyé par le serveur. L'outil distingue aussi les échecs survenus avant l'ouverture de la connexion des coupures survenues après, et liste les causes habituelles de chacun.
Puis-je ajouter un en-tête Authorization ou un autre en-tête personnalisé ?
Non. L'API WebSocket du navigateur ne permet pas aux pages web de définir des en-têtes de requête ; le navigateur envoie un ensemble fixe (dont Origin et les cookies du site du serveur). Contournements courants, selon ce que votre serveur prend en charge : un jeton dans l'URL, comme wss://host/ws?token=… ; un jeton transmis comme sous-protocole (seuls les caractères de type token sont autorisés, donc un JWT fonctionne mais pas un Base64 standard contenant = ou /, et le serveur doit renvoyer le sous-protocole) ; ou un cookie, que les navigateurs n'envoient de façon fiable qu'au site de la page elle-même, si bien que depuis cette page il n'atteint généralement pas votre serveur. Des outils comme Postman peuvent définir des en-têtes parce que ce ne sont pas des navigateurs.
Pourquoi cela fonctionne-t-il dans Postman mais pas ici ?
Postman et les clients en ligne de commande peuvent définir n'importe quel en-tête et n'envoient généralement pas d'Origin. Un navigateur ne peut pas ajouter d'en-tête Authorization et envoie toujours Origin: https://go-tools.org. Si le serveur exige un jeton dans un en-tête ou vérifie l'Origin, il rejette le handshake du navigateur ; autorisez l'Origin ou transmettez le jeton autrement.
Le heartbeat envoie-t-il des trames ping WebSocket ?
Non. Les pages web ne peuvent ni envoyer ni voir les trames ping/pong du protocole ; quand le serveur envoie un ping, le navigateur répond lui-même par un pong. L'envoi périodique de cet outil envoie un message texte ordinaire, comme {"type":"ping"}, à l'intervalle que vous fixez. Il est désactivé par défaut, car un serveur qui n'attend pas ce message peut fermer la connexion. Pour maintenir une connexion inactive à travers un proxy, faites envoyer les pings par le serveur.
Pourquoi ne puis-je pas me connecter à mon serveur Socket.IO ?
Socket.IO est un protocole au-dessus de WebSocket, pas du WebSocket brut. Un serveur Socket.IO v3/v4 attend le chemin /socket.io/?EIO=4&transport=websocket, envoie un paquet d'ouverture commençant par 0, attend 40 pour rejoindre le namespace par défaut, et ferme la connexion si chaque ping 2 ne reçoit pas de pong 3. Choisissez le préréglage Socket.IO et l'outil fait tout cela ; envoyez ensuite les événements sous la forme 42["event","data"]. Les serveurs configurés uniquement pour le long-polling HTTP n'acceptent pas du tout de WebSocket.
Ma connexion tombe au bout d'environ une minute — pourquoi ?
Le plus souvent, c'est un délai d'inactivité dans un proxy inverse. Par défaut, Nginx ferme une connexion relayée quand aucune donnée ne passe pendant 60 secondes (proxy_read_timeout), et la page voit le code 1006. Augmentez ce délai ou faites envoyer des trames ping par le serveur. Derrière Nginx, vérifiez aussi que le proxy transmet l'upgrade avec proxy_set_header Upgrade $http_upgrade; et proxy_set_header Connection "upgrade"; (avant Nginx 1.29.7, ajoutez aussi proxy_http_version 1.1;).
Comment me connecter à un serveur wss:// avec un certificat auto-signé ?
Ouvrez https://le-meme-hote:port/ dans un nouvel onglet, acceptez l'avertissement de certificat, puis revenez et connectez-vous. Le navigateur mémorise l'exception pour cet hôte et ce port. Ne le faites que pour vos propres serveurs de test, car cela réduit la protection du navigateur.
Comment envoyer et lire des messages binaires ?
Choisissez HEX ou Base64 comme format d'envoi. Le HEX accepte 48 69 00 FF, 0x48,0x69 ou 486900FF ; l'aperçu montre les octets, et les caractères invalides ou un nombre impair de chiffres sont signalés avec leur position au lieu d'être envoyés. Les messages binaires reçus s'affichent en HEX, 16 octets par ligne, et la barre d'outils du journal permet de les basculer en Base64. Pour lire le HEX reçu sous forme de texte, collez-le dans Hexadécimal en texte.
Mes messages passent-ils par les serveurs de go-tools ?
Non. Votre navigateur se connecte directement à l'adresse que vous saisissez, et les messages ne passent pas par nos serveurs. L'outil n'ouvre d'ailleurs aucune connexion WebSocket tant que vous n'avez pas cliqué sur Se connecter, et il ne garde l'adresse et les messages qu'en mémoire — ni dans l'URL de la page ni dans le stockage du navigateur. Comme le reste du site, cette page charge des scripts d'analyse d'audience et de publicité.
Existe-t-il un serveur sur lequel je puisse faire des tests ?
Utilisez l'écho local : il tourne dans cette page, renvoie tout ce que vous envoyez et n'établit aucune connexion réseau. Des services d'écho publics comme wss://echo.websocket.org/ existent aussi, mais ce sont des tiers : leur disponibilité n'est pas garantie, et vos messages sont transmis à ce tiers.

Outils connexes

Voir tous les outils →

Générateur & Constructeur de commande cURL

Web & API

Construisez des commandes curl dans votre navigateur — méthode, en-têtes, authentification et corps, obtenez instantanément une commande prête à copier. Préréglages Bearer, POST JSON, upload. Gratuit, privé, sans inscription.

Générateur htpasswd — bcrypt, Apache MD5 (apr1), Basic Auth

Web & API

Générez des entrées htpasswd avec bcrypt, Apache MD5 (apr1), SHA-1 et plus. Obtenez des configs Apache, nginx et Docker prêtes à coller. 100 % dans votre navigateur — aucun envoi.

Générateur de balises meta & Open Graph

Web & API

Générez des balises Open Graph, Twitter Card et SEO avec un aperçu en direct pour Google, Facebook et X. 100 % gratuit, dans le navigateur, sans inscription — copiez-collez le code.

Testeur nginx location — pourquoi ce bloc l'emporte

Web & API

Quel bloc location nginx l'emporte — et pourquoi les autres ont perdu. Testeur gratuit pour =, ^~, ~ et ~*, tout dans votre navigateur.

Terminal série en ligne (moniteur série Web Serial)

Web & API

Moniteur série dans Chrome ou Edge, sans installation : CH340, CP2102, ESP32 ou Arduino, envoi texte ou HEX en boucle, CRC-16 Modbus ajouté d'office. Texte illisible ? L'outil repère le GBK et réaffiche les données déjà reçues.

Calculateur de sous-réseau IPv4

Web & API

Calculez adresse réseau, diffusion, plage d'hôtes utilisables, masque de sous-réseau et masque générique de tout bloc CIDR IPv4. Gère les liens /31 (RFC 3021), découpe un bloc en sous-réseaux. 100 % dans le navigateur.