HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ColdHeat
pybluemonday
Python2020–2021
ColdHeat / pybluemonday

pybluemonday

pybluemonday is a library for sanitizing HTML very quickly via bluemonday.

2Distinct people
3Mentions
0Explicit recommenders
42GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

pybluemonday is a library for sanitizing HTML very quickly via bluemonday.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week3 dated mentions

Observed mentions: 2020-12-14 17:55:20 UTC to 2021-05-06 12:01:37 UTC. Weeks start Monday, UTC.

0122020-12-14 00:00:00 UTC to 2020-12-21 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 commentsDec 142020-12-21 00:00:00 UTC to 2020-12-28 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-12-28 00:00:00 UTC to 2021-01-04 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-04 00:00:00 UTC to 2021-01-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-11 00:00:00 UTC to 2021-01-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-18 00:00:00 UTC to 2021-01-25 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-25 00:00:00 UTC to 2021-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-02-01 00:00:00 UTC to 2021-02-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-02-08 00:00:00 UTC to 2021-02-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-02-15 00:00:00 UTC to 2021-02-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-02-22 00:00:00 UTC to 2021-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsFeb 222021-03-01 00:00:00 UTC to 2021-03-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-03-08 00:00:00 UTC to 2021-03-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-03-15 00:00:00 UTC to 2021-03-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-03-22 00:00:00 UTC to 2021-03-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-03-29 00:00:00 UTC to 2021-04-05 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-04-05 00:00:00 UTC to 2021-04-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-04-12 00:00:00 UTC to 2021-04-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-04-19 00:00:00 UTC to 2021-04-26 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-04-26 00:00:00 UTC to 2021-05-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-05-03 00:00:00 UTC to 2021-05-10 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsMay 3

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Dec 142020-12-14 00:00:00 UTC2020-12-21 00:00:00 UTC211
Dec 212020-12-21 00:00:00 UTC2020-12-28 00:00:00 UTC000
Dec 282020-12-28 00:00:00 UTC2021-01-04 00:00:00 UTC000
Jan 42021-01-04 00:00:00 UTC2021-01-11 00:00:00 UTC000
Jan 112021-01-11 00:00:00 UTC2021-01-18 00:00:00 UTC000
Jan 182021-01-18 00:00:00 UTC2021-01-25 00:00:00 UTC000
Jan 252021-01-25 00:00:00 UTC2021-02-01 00:00:00 UTC000
Feb 12021-02-01 00:00:00 UTC2021-02-08 00:00:00 UTC000
Feb 82021-02-08 00:00:00 UTC2021-02-15 00:00:00 UTC000
Feb 152021-02-15 00:00:00 UTC2021-02-22 00:00:00 UTC000
Feb 222021-02-22 00:00:00 UTC2021-03-01 00:00:00 UTC000
Mar 12021-03-01 00:00:00 UTC2021-03-08 00:00:00 UTC000
Mar 82021-03-08 00:00:00 UTC2021-03-15 00:00:00 UTC000
Mar 152021-03-15 00:00:00 UTC2021-03-22 00:00:00 UTC000
Mar 222021-03-22 00:00:00 UTC2021-03-29 00:00:00 UTC000
Mar 292021-03-29 00:00:00 UTC2021-04-05 00:00:00 UTC000
Apr 52021-04-05 00:00:00 UTC2021-04-12 00:00:00 UTC000
Apr 122021-04-12 00:00:00 UTC2021-04-19 00:00:00 UTC000
Apr 192021-04-19 00:00:00 UTC2021-04-26 00:00:00 UTC000
Apr 262021-04-26 00:00:00 UTC2021-05-03 00:00:00 UTC000
May 32021-05-03 00:00:00 UTC2021-05-10 00:00:00 UTC101

What Hacker News says

3 sources
My thoughts as a maintainer of a HTML sanitizer in Go https://github.com/microcosm-cc/bluemonday which is also available to Python via https://github.com/ColdHeat/pybluemonday 1. Sanitizing is not difficult, defining the policy/config is. This is difficult as your need is not someone else's. First glance of this proposal is that this needs a lot more work to cover people's needs. It's good enough, but will have a lot of edges and will need to evolve. 2. If you allow a blocklist then it will be less secure. Because people will use that by default as it's easier to say "I don't want <blink>" than it is to say "I only accept <long list of things and the myriad of when attributes are valid on which elements>". The problem here is that a blocklist requires the person writing the config to cover every scenario to be safe and unless they're a se
Read the rest
curity engineer they will not... and if they were a security engineer they'd use the allowlist. Blocklists seldom deliver good security, allowlists deliver great security. 3. Provide sane defaults. Most engineers simply do not know what is safe or not. I ship a policy in bluemonday for user generated content... it is safe by default and good enough for most people, and it can be taken and extended due to the way the API is structured so can cover other scenarios as a foundation policy. ----- I think the proposal in general: specify a standard for a sanitization API has merit. But mostly it has merit if it specifies a standard for defining sanitization policies/configuration, allowing them to be portable across different languages and systems. The one I wrote is very heavily inspired by https://github.com/owasp/java-html-sanitizer which is the OWASP project one maintained by Mike Samuel. When I did my research before writing the Go one, this was far and away the best way to construct the policy/config and I already saw that this perspective was more valuable than whether it's a token based parser (GIGO but low memory) or a DOM builder (more memory)... no-one cares about the internals, they care about expressing what safe means to them.
In HTML Sanitizer API
Author here. Recently I was looking for a way to sanitize user generated HTML of malicious things like JavaScript. Solutions like bleach, html_sanitizer, and lxml's Cleaner all work but I found that their performance on complicated HTML snippets were lacking because they needed to rely on html5lib for parsing HTML5. And completely normal content would get mangled without using html5lib. I ended up writing these Python bindings to the bluemonday library. It seems to perform much better than existing Python solutions for the same problem[2]. I suspect because more of the work can be done in native code instead of having to pass an XML tree around. Hoping that this is useful to someone else but also looking for any feedback. Especially about how the bindings were written. [1] https://github.com/microcosm-cc/bluemonday [2] https://github.com/
Read the rest
In Show HN: Fast HTML Sanitization in Python

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.