# flutter_widget_from_html: rendering HTML as Flutter widgets, one package per media type

> The daohoangson/flutter_widget_from_html repository is a monorepo behind the flutter_widget_from_html package and seven companion packages on pub.dev, covering hyperlinks, images, audio, video, SVG and embedded web content. Its main appeal is widget-based rendering, and its main uncertainty is how unevenly HTML tag support is documented.

**daohoangson/flutter_widget_from_html** — Flutter package to render html as widgets that supports hyperlink, image, audio, video, iframe and many other tags.

- Repository: https://github.com/daohoangson/flutter_widget_from_html
- Website: https://pub.dev/packages/flutter_widget_from_html
- Stars: 781 · Forks: 290
- Language: Dart
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/daohoangson-flutter-widget-from-html

## One repository, nine published packages

The repository is a monorepo and the README opens by saying exactly that: it contains the source code for everything HtmlWidget related. The package table then lists the pieces.

At the top sit the two core packages, `flutter_widget_from_html` in the `packages/enhanced/` directory and `flutter_widget_from_html_core` in `packages/core/`. Below them are seven add-on packages, each in its own directory: `fwfh_cached_network_image`, `fwfh_chewie`, `fwfh_just_audio`, `fwfh_svg`, `fwfh_url_launcher` and `fwfh_webview`.

That structure tells you the design. The core package handles the general case of turning HTML into widgets, and the media specific problems are split into small optional packages rather than being folded into one dependency. An app that renders text with hyperlinks and nothing else does not need to take on a video player or an SVG renderer. A Flutter developer who has been burned by a package that pulls in every media stack at once will recognise the value of that split.

The repository also holds the supporting pieces of a real project: a `demo_app/` directory, a `docs/` directory, a `tool/` directory, `AGENTS.md` and `CLAUDE.md` for agent and contributor instructions, `SECURITY.md`, `renovate.json` for dependency updates, `.codecov.yml`, `sonar-project.properties`, a `.devcontainer/` and a `.git-crypt/` directory. The presence of SonarCloud and Codecov configuration says coverage is measured, and the README carries a coverage badge for new code.

## The core package turns tags into widgets instead of into a webview

The package description states that flutter_widget_from_html renders HTML as widgets, and that it supports hyperlink, image, audio, video, iframe and many other tags. That is the whole mechanism in one sentence, and the interesting part is what it excludes.

A webview based approach hands the HTML to a browser engine and treats the result as an opaque surface. The widget approach parses the HTML and produces Flutter widget trees, so the result composes with the rest of your layout, scrolls with your own `ScrollController`, and can be styled with the same theme data as the rest of your app. The cost is that every tag and attribute you care about has to be implemented, which is exactly why the tag list is long and why the packages are split up.

The `fwfh_webview` package in the list shows that the project does not pretend the webview approach is obsolete. It sits beside the widget packages as another route for content that a widget tree cannot express, most plausibly for embedded frames given that iframe is one of the advertised tags. The repository's own published comparison between its two approaches is the honest way to pick, and the README does not resolve it for you.

For the add-on packages, the names carry the intent. `fwfh_cached_network_image` is for remote images, `fwfh_chewie` for video playback, `fwfh_just_audio` for audio, `fwfh_svg` for SVG, `fwfh_url_launcher` for opening links in the system browser, and `fwfh_webview` for embedded web content. Each one is a separate pub.dev package, so you add only the capability your content needs.

## Getting started goes through pub.dev, the demo app and a hosted dartpad

The README does not give a command line install step, so there is no code to copy for installation. The packages are published on pub.dev, and the README links each one in the package table, so the route is the standard pub.dev dependency declaration for the package you need, starting with `flutter_widget_from_html` itself and adding the companion packages only when your HTML needs them.

For trying the library before you add it to a project, the README points at two things. The first is the demo app, published at demo.fwfh.dev, which includes a supported tags page at demo.fwfh.dev/supported/tags.html. The second is a special dartpad at try.fwfh.dev that is preloaded with the project's packages, so you can write a widget in the browser and see the result without a local toolchain.

That hosted dartpad is the fastest first check for a new user, and it is the right place to answer a question the README leaves open: how the library behaves with your own HTML, in a real widget tree, before you commit a dependency to a production app.

The demo app is also the place to see tag coverage in practice. The supported tags page is a matrix rather than a promise, and walking it before writing code is a better use of an afternoon than discovering an unsupported tag after your content pipeline is already built.

## Tag coverage is published as a matrix, and that is where the uncertainty sits

Two facts about coverage stand out, and they point in opposite directions.

The first is that the package advertises support for hyperlink, image, audio, video, iframe and many other tags. The second is that the project publishes a page listing supported tags rather than documenting a complete, uniform behaviour for the whole HTML specification. For a renderer whose entire purpose is to be handed HTML it did not write, that gap between an advertised tag list and a behaviour matrix is the real limitation.

The README does not document what happens to an unsupported tag or attribute. It does not say whether the element is dropped, rendered as plain text, or passed through to the webview route. If your content contains a table, a form, or a CSS rule that the core does not model, the behaviour is something you have to check in the demo app rather than read in the documentation.

There is a second limitation worth stating plainly. A widget renderer has to be a good citizen in the widget tree, and the repository does not describe how it behaves inside a scrolling list, how it handles a very large document, or how it copes with a `ListView` that rebuilds often. The presence of `flutter_widget_from_html_core` as a separate package from `flutter_widget_from_html` suggests a split between a lower level core and an enhanced layer, and the README does not spell out the boundary between them, so an app that needs a specific behaviour should check which package provides it before depending on the higher level one.

For content you control, none of this matters much. The library earns its keep on the HTML you did not write, and that is also where the tag matrix should shape your decision.

## Version 0.17.2, an MIT licence and a repository still taking commits

The version line moves in small steps. The most recent release is v0.17.2 on 2026-04-06, preceded by v0.17.1 on 2025-08-31 and v0.17.0 on 2025-07-15. The last push to the repository was on 2026-10-15, and the repository is not archived, so work continues between releases rather than only at release time.

The package is still below 1.0.0, and the README does not lay out a compatibility policy for the 0.x line. In practice that means you should pin a specific version in your project manifest rather than take a floating constraint, and read the changelog for the version you move to. The gap between v0.17.0 in July 2025 and v0.17.1 in August 2025, followed by a longer gap to April 2026, is a reminder that this is a project with a steady but unhurried release rhythm rather than a fast moving one.

Licensing is simple. The repository carries a `LICENSE` file, the project is MIT licensed, and the MIT terms are permissive enough for commercial applications and for closed source products without any copyleft obligation. For a package whose whole job is rendering content, the licence is rarely the deciding factor, and the tag support matrix is.

The tooling around the repository is worth one more mention for teams that care about supply chain hygiene. `renovate.json` handles dependency updates, `.codecov.yml` and `sonar-project.properties` track coverage, `.github/` holds the workflow that produces the Flutter badge in the README, and `SECURITY.md` gives a place for vulnerability reports.

## Conclusion

Adopt flutter_widget_from_html when your Flutter app has to display HTML it does not control, such as content from a CMS, and you want that content to become real widgets rather than a webview. Do not adopt it for a fixed, known layout, where hand written Flutter widgets are cheaper, and do not adopt it on the assumption that every tag works, since the repository publishes a tag support matrix instead of promising uniform coverage. Before you commit, open the supported tags page on the demo site, check the tag list against the HTML your backend actually serves, and pick the companion package that matches your media type, for example fwfh_cached_network_image for remote images or fwfh_chewie for video.

## FAQ

### What does flutter_widget_from_html do and where do I get it?

It is a Flutter package that renders HTML as widgets, supporting tags including hyperlink, image, audio, video and iframe. The packages are published on pub.dev, and the repository also links a demo app and a hosted dartpad for trying them out.

### Which companion packages ship with flutter_widget_from_html?

The monorepo lists fwfh_cached_network_image, fwfh_chewie, fwfh_just_audio, fwfh_svg, fwfh_url_launcher and fwfh_webview alongside flutter_widget_from_html and flutter_widget_from_html_core. Each is published separately on pub.dev, so you can add only the capability you need.

### How can I check which HTML tags flutter_widget_from_html supports?

The README points to a supported tags page in the demo app at demo.fwfh.dev/supported/tags.html. The README does not describe the behaviour for tags outside that list, so unsupported markup should be tested in the demo app or the hosted dartpad.

## Sources

- [daohoangson/flutter_widget_from_html on GitHub](https://github.com/daohoangson/flutter_widget_from_html)
- [License: MIT](https://github.com/daohoangson/flutter_widget_from_html/blob/master/LICENSE)
- [Project website](https://pub.dev/packages/flutter_widget_from_html)
- [README](https://github.com/daohoangson/flutter_widget_from_html/blob/master/README.md)
- [Releases](https://github.com/daohoangson/flutter_widget_from_html/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/daohoangson-flutter-widget-from-html