Lancement à vie— 23 sur 100 places à $49 · $99Réserver
Hébergement HTML

Hébergez un fichier HTMLcomme lien en direct

Déposez un seul fichier HTML ici et obtenez un lien unique qui l'affiche en direct dans le navigateur — aucun serveur, aucun DNS, aucune étape de build.

Déposez your file ici

Déposez-en plusieurs d'un coup : ils deviennent un seul lien d'album

Jusqu'à 100 MB gratuit

Gratuit : 20 liens, jusqu'à 100 MB · Pro : liens illimités, fichiers plus volumineux

Hébergez un fichier HTML en quatre étapes

  1. 1

    Regroupez tout dans un seul fichier autonome

    Intégrez votre CSS dans une balise <style> et votre JS dans une balise <script>, et référencez les images par des URL https:// complètes ou en data URI base64. Si votre CSS/JS/images se trouvent actuellement dans des fichiers séparés, c'est la seule étape de préparation qui compte — tout ce dont la page a besoin doit se trouver dans l'unique fichier .html que vous importez.

  2. 2

    Importez le fichier .html

    Glissez-le sur la carte et connectez-vous avec Google — un clic, aucun formulaire. Un compte gratuit vous donne 20 pages hébergées, jusqu'à 100 MB chacune. Le fichier est validé par ses octets réels, pas par son nom, donc seul du HTML authentique est accepté.

  3. 3

    Ouvrez le lien en direct pour vérifier le rendu

    Votre page est servie sur un lien propre et partageable, affiché en direct dans une vue de navigateur en bac à sable. Ouvrez-le vous-même d'abord — comme les scripts s'exécutent de façon isolée, une page qui cherche à atteindre une fenêtre parente ou un cookie de même origine se comportera différemment que sur localhost. Corrigez et réimportez si nécessaire.

  4. 4

    Partagez le lien (ou son code QR)

    Envoyez l'URL, ou téléchargez le code QR généré automatiquement pour l'insérer dans une diapositive, une impression ou une affiche. Chaque ouverture incrémente un compteur de vues pour que vous voyiez que la page est vraiment consultée.

Un site d'une page sans la moindre infrastructure

Le cas classique : vous avez codé à la main un index.html — une page « bientôt disponible », un RSVP d'événement, un link-in-bio, une page de détails de mariage — et chaque guide d'hébergement veut que vous achetiez un domaine, pointiez des serveurs de noms et attendiez la propagation. Ici, la page est en ligne dès que l'import est terminé, sur un lien que vous pouvez partager par SMS. Comme elle s'affiche en direct plutôt que de montrer le code, les visiteurs voient la vraie page, avec sa mise en page, ses polices et ses états au survol intacts. La limite honnête : c'est vraiment un seul fichier. Si votre site, c'est index.html plus un dossier /css et un dossier /images, soit vous intégrez tout dans cet unique fichier, soit ce n'est pas le bon outil — un tas de fichiers séparés ne se connecte pas tout seul.

Partager un rapport HTML exporté

De nombreux outils exportent un .html autonome : un rapport de couverture pytest ou Jest, une exécution Playwright, un résumé Allure ou pandas-profiling, un audit Lighthouse, un notebook Jupyter enregistré en HTML. Ils sont déjà conçus comme un seul fichier avec tout intégré, ce qui en fait une correspondance quasi parfaite. Plutôt que de compresser le rapport et de l'envoyer par e-mail — où le destinataire doit le télécharger, le décompresser et trouver le fichier d'entrée —, vous envoyez un seul lien qui ouvre le rapport interactif dans son navigateur. Le compteur de vues vous indique que le client ou le collègue l'a vraiment ouvert, et le lien continue de fonctionner pour la prochaine personne qui en a besoin. Les graphiques interactifs et les tableaux repliables continuent de fonctionner tant que leur JS a été intégré dans l'export.

Prévisualiser un e-mail ou une newsletter codés

L'e-mail HTML est un format pénible en soi — tableaux imbriqués, styles en ligne, aucune feuille de style externe — et avant de lancer une campagne, vous voulez qu'un décideur voie le résultat rendu, pas le code source. Collez votre sortie Mailchimp, Klaviyo ou compilée en MJML dans un fichier .html, hébergez-le et envoyez le lien pour validation. Deux mises en garde honnêtes à préciser d'emblée : un rendu navigateur n'est pas un vrai rendu de boîte de réception (Gmail et Outlook réécrivent les choses à leur façon, donc utilisez ceci pour la relecture de la mise en page et du texte, pas pour le contrôle qualité final), et les pixels de suivi ou liens de suivi de clics intégrés à l'export continueront de pointer vers votre ESP. Retirez-les de la copie de relecture si vous ne voulez pas que vos propres ouvertures de test soient comptabilisées.

Un extrait de landing ou une démo de code rendus

Quand vous prototypez, vous avez souvent un seul fichier qui représente tout : un hero de landing avec Tailwind via CDN, une animation CSS dont vous êtes fier, un croquis en canvas, une petite démo D3 ou Three.js, un composant créé pour le montrer à un client. Un lien en direct l'emporte sur un CodePen ou une capture d'écran quand vous voulez que ça ressemble à une vraie page sur une vraie URL — sans l'habillage de l'éditeur autour, s'ouvre en plein écran sur un téléphone. Tant que vos bibliothèques se chargent via https depuis un CDN et que votre code est intégré, ça fonctionne. C'est le moyen le plus rapide de transformer « voici une idée brute » en « ouvrez ceci sur votre téléphone », sans pipeline de déploiement.

Pourquoi le rendu se fait dans un bac à sable (et ce que cela signifie)

Votre HTML est servi dans un cadre en bac à sable sans accès de même origine. Cela vous protège, vous et chaque visiteur : un balisage non fiable ne peut pas lire les cookies, ne peut pas atteindre la page parente et ne peut pas se faire passer pour une partie de l'hôte. Pour 95 % des pages — mise en page, styles, animations, bibliothèques CDN, scripts autonomes — vous ne le remarquerez jamais. Là où vous le remarquerez : un code qui suppose posséder la fenêtre de premier niveau, qui a besoin de cookies internes ou de localStorage, ou qui communique avec une API n'autorisant qu'une origine précise (CORS). Ce sont des besoins d'application sur mesure, et pour cela un vrai hébergeur est le bon choix. Sur l'offre Pro, vous pouvez placer une page hébergée sur votre propre domaine dans la barre d'adresse avec SSL automatique, mais la page continue de s'afficher en bac à sable, donc les mêmes limites de script s'appliquent. Pour héberger une page destinée à être consultée, le bac à sable est une fonctionnalité, pas une limite.

Pour qui c'est fait — et qui devrait chercher ailleurs

Idéal pour : développeurs, designers, étudiants, marketeurs et créateurs no-code qui ont un .html unique terminé et ont besoin d'une URL maintenant — une démo pour un client, un rapport pour un manager, un extrait pour un collègue, une page unique pour un événement. Pas le bon choix pour : un site multi-pages avec des liens internes entre fichiers .html, une application qui a besoin d'un backend ou de variables d'environnement, tout ce qui exige votre propre domaine dans la barre d'URL, ou une étape de build qui génère un dossier /dist avec des ressources séparées. Pour cela, utilisez un vrai hébergeur. Si votre seul blocage était « je ne veux pas configurer un hébergement pour un seul fichier », ceci lève exactement ce blocage, et rien de plus.

Questions fréquentes

Toujours bloqué ? Écrivez-nous directement — une vraie personne vous répond.

Oui. Tout ce dont la page a besoin doit se trouver dans l'unique fichier ou se charger depuis une URL https:// — intégrez votre CSS et JS, et référencez les images sous forme d'URL complètes ou de data URI base64. Des fichiers .css/.js séparés ou un dossier d'images ne seront pas liés.

Votre lien est à 10 secondes

Connectez-vous gratuitement avec Google — un clic, aucun formulaire — et partagez un lien propre et traçable.

Commencer gratuitement

Explorer plus

Lien de portfolio Alternative à Tiiny Host Partage en lecture seule Fichiers en ligne