# django-tinymce: TinyMCE 7.8.0 Integration for Django Forms

> django-tinymce gives Django developers a TinyMCE-backed form widget and an HTMLField for rich HTML content. It is a practical choice for Django 4.2 through 5.2 projects that already want the browser editor supplied by TinyMCE.

**jazzband/django-tinymce** — TinyMCE integration for Django

- Repository: https://github.com/jazzband/django-tinymce
- Website: http://django-tinymce.readthedocs.org/
- Stars: 1,355 · Forks: 322
- Language: JavaScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/jazzband-django-tinymce

## The Django form field django-tinymce replaces

django-tinymce addresses a narrow integration problem: rendering a Django form field with the TinyMCE rich-text editor rather than an ordinary text control. It is intended for developers building Django applications that accept formatted content through forms. The project offers a model field, HTMLField, and also documents use of a widget in situations where a model field is unnecessary. That distinction matters because the quickstart connects the editor to persisted model content, while form-only use can remain a rendering concern.

The package targets Python 3.9 and later. Its project metadata lists support for Django 4.2, 5.0, 5.1, and 5.2, while the dependency declaration requires Django 4.2 or newer. The README identifies TinyMCE 7.8.0 as the bundled editor version. This is a server-side Django application with JavaScript editor assets, not a standalone TinyMCE editor or an API for processing documents outside a Django form.

The appropriate user is therefore a Django developer who has already selected TinyMCE as the browser editing interface. The package does not present itself as a general content management system, collaborative editor, or sanitization layer. Its scope is the bridge between Django's field and widget APIs and TinyMCE's browser resources. Projects that only need a plain multiline form value may find that the package adds an editor and static assets without addressing the application requirement.

## HTMLField, widgets, and the request path

The visible integration has three parts. First, the project installs itself as a Django application named tinymce. Second, the site's URL configuration includes tinymce.urls at a tinymce/ path. Third, application code imports HTMLField from tinymce.models and assigns it to a model attribute. The resulting data path begins with a form field rendered through django-tinymce, continues through the editor interface served by Django's static-file integration, and returns submitted form data through Django's normal form and model machinery.

The README does not specify a custom API endpoint for saving content, nor does it describe any separate database service. Its quickstart adds the URL include under tinymce/, but it does not state that every application needs a bespoke route beyond that inclusion. The editor assets are provided through Django's staticfiles mechanism. Based on the documented setup, the package expects the normal Django static-file and template pipeline to handle asset delivery.

HTMLField is the fastest route when the content is a model attribute. The README also says that using the widget instead of HTMLField is available in the documentation. That is a real design choice within this project. HTMLField couples the editor choice to the model declaration. A widget attaches the editor at the form rendering layer, which can fit an application whose editor choice is confined to a particular form or view. The available quickstart does not show the widget declaration, so its complete configuration should be taken from the linked project documentation rather than inferred.

## Installing django-tinymce and adding HTMLField

The README's quickstart starts by installing the Python package. This adds django-tinymce to the environment used by the Django project. The command below is copied directly from the documented quickstart.

```bash
$ pip install django-tinymce
```

After installation, add the tinymce application to INSTALLED_APPS. The ellipsis in this example represents the project's existing entries.

```python
INSTALLED_APPS = (
    ...
    'tinymce',
)
```

The application's root URL configuration then includes the package URLs. The documented path is tinymce/.

```python
urlpatterns = [
    ...
    path('tinymce/', include('tinymce.urls')),
]
```

For the first model-backed editor field, import HTMLField and declare it on a model. The README's example leaves the rest of the model unspecified, but the field itself is complete.

```python
from django.db import models
from tinymce.models import HTMLField

class MyModel(models.Model):
    ...
    content = HTMLField()
```

After adding the field, the project needs its normal Django migration process so the model change is reflected in the database schema. The README does not provide the generated migration command or migration file, so it does not establish whether HTMLField requires any special database column customization. Run the migration procedure already used by the target Django project rather than assuming a package-specific migration command.

## Static assets and the real browser-side boundary

The package uses Django staticfiles, according to the README. That makes static-file configuration part of the first-use checklist, particularly for deployments that do not serve application assets directly from the Django process during development. The quickstart does not document a separate `python manage.py` command for collecting or publishing assets, and it does not list proxy, cache, or content-security-policy settings.

This boundary has an operational consequence. django-tinymce can declare the field and include its URLs, but a deployment still needs to deliver the JavaScript and related editor resources through the project's normal static-file setup. If those resources are not available at the URLs generated by the deployment, the form cannot initialize the TinyMCE interface as intended. The documentation's phrase that "everything should work as expected" is based on ordinary Django staticfiles behavior, not a documented fallback for static assets.

The editor is also a browser component. HTMLField provides the Django-side field integration, but the README does not claim that django-tinymce sanitizes submitted HTML, transforms it into another storage format, or synchronizes edits between users. It also does not describe collaboration, revision history, media upload, or image processing. Those concerns would need separate application or service decisions. Treating the package as the complete content-authoring system would extend it beyond the mechanism documented here.

## Version boundaries and upgrade work

The repository was not archived, and its last push was on 2026-10-12. The package metadata declares version 5.0.0, supports Python 3.9+, and requires Django 4.2 or later. The README states support for Django 4.2 through 5.2 and TinyMCE 7.8.0. The release history lists 4.1.0 on 2024-06-21, 4.0.0 on 2024-04-22, and 3.5.0 on 2022-08-27. Those two version sources should be reconciled before deployment: repository metadata names 5.0.0, while the listed releases stop at 4.1.0.

An upgrade can affect more than Python dependency resolution because editor assets are part of the integration. django-tinymce declares a Django dependency, while the bundled editor version is documented separately. Teams changing Django, Python, django-tinymce, or TinyMCE-facing configuration should review the changelog and test form rendering, submission, and static-asset delivery in the target environment.

The README does not document an automatic migration path, rollback procedure, compatibility matrix for individual TinyMCE plugins, or a long-term-support policy. It directs support requests to GitHub issues. Based on the available repository information, maintenance is recent, but upgrade planning still requires checking the changelog for the exact package version being installed.

## License metadata differs across project files

The project is identified by the MIT License in the repository description and README. The packaging metadata is more specific: pyproject.toml declares `MIT AND GPL-2.0-or-later` and lists both `LICENSE.txt` and `tinymce/static/tinymce/license.md` as license files. This is a licensing boundary worth resolving during adoption rather than treating as a minor README inconsistency.

The package metadata declares `MIT AND GPL-2.0-or-later` and lists two license files, while the README describes django-tinymce itself as MIT licensed. The available files do not provide legal guidance about how a particular deployment must comply. They do make the declarations relevant to review. Engineers should compare the package license statement with the bundled editor license when preparing distribution obligations or reviewing the repository files shipped by the chosen package.

This is also a concrete upgrade check. If a future django-tinymce release changes the bundled TinyMCE version or its license file, the metadata may change with it. The current facts support checking both license identifiers and both referenced files, but they do not support a legal conclusion about redistribution.

## Choosing between HTMLField and the widget path

The clearest alternative presented by django-tinymce itself is its widget rather than its model field. HTMLField places the TinyMCE choice in the model schema and is the path shown in the quickstart. The widget applies the editor through Django's form-rendering layer and is the documented option for different use cases. A project that stores TinyMCE-authored content as part of a model can start with HTMLField. A project that only needs a rich-text input in a particular form may prefer the widget path.

This comparison should not be mistaken for a comparison with another named editor package. The project documentation does not document a substitute third-party integration. It also does not specify the widget's complete constructor syntax. The real architectural decision is scope: model-level convenience versus form-level attachment.

django-tinymce is the wrong choice when the application does not need TinyMCE, when the team wants only Django's standard text entry behavior, or when the required static asset delivery cannot be supported. It is also a poor fit if the application expects the package alone to provide HTML sanitization, collaborative editing, or document storage beyond a Django field. Verify those separate requirements before adding the dependency.

## Conclusion

Adopt django-tinymce when a Django project needs TinyMCE in a form field and can accept the package's editor asset and HTML storage model. Do not choose it merely because rich-text markup is required without first deciding whether the form widget or HTMLField fits the application. Before upgrading, verify the deployed package version, the bundled TinyMCE version, static-file delivery, and the combined licensing metadata in pyproject.toml.

## FAQ

### How do I install django-tinymce in a Django project?

Install it with `pip install django-tinymce`, add `'tinymce'` to `INSTALLED_APPS`, and include `tinymce.urls` under the documented `tinymce/` path. The README also states that the package uses Django staticfiles.

### Which Django and Python versions does django-tinymce support?

The README states Python 3.9+ and Django 4.2 through 5.2. The project metadata requires Python 3.9 or later and Django 4.2 or later.

### Can django-tinymce be used without declaring an HTMLField?

Yes. The README says that different use cases, including using a widget instead of HTMLField, are covered in the project documentation. The quickstart only shows the HTMLField approach.

## Sources

- [jazzband/django-tinymce on GitHub](https://github.com/jazzband/django-tinymce)
- [License: MIT](https://github.com/jazzband/django-tinymce/blob/master/LICENSE)
- [Project website](http://django-tinymce.readthedocs.org/)
- [README](https://github.com/jazzband/django-tinymce/blob/master/README.md)
- [Releases](https://github.com/jazzband/django-tinymce/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jazzband-django-tinymce