A Little Halloween Magic for Any Website

A developer built the Halloween Website Decorator, a Flask web app that takes a public URL or uploaded HTML/CSS/image files and generates an isolated, Halloween-themed static preview alongside the original page. The app uses OpenAI-compatible chat-completion providers to return a constrained line-based design description—a theme choice and allowed decoration slots—rather than generating HTML, with hand-authored SVG assets, CSS sanitization, retries, fallback providers, bounded background jobs, caching, and a fixture matrix testing five sample pages across three intensity levels.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine https://dev.to/challenges/hacktoberfest-week4-2026-10-26 Every October, the internet fills with spooky colors, glowing pumpkins, and tiny bats flying across the screen. I wanted to bring some of that seasonal fun to the websites people already use—not by rebuilding them, but by giving them a temporary Halloween makeover. That idea became the Halloween Website Decorator : a small web app that takes a public website or uploaded HTML files and turns them into an isolated, Halloween-themed preview. The app accepts either a public URL or a website upload. For uploads, you can provide one HTML file with optional CSS and images, or a ZIP containing those files. It then prepares a static copy, chooses a theme, adds decorations, and opens the result beside an original-page view. The design is intentionally a collaboration between code and AI: The result is meant to feel like a seasonal mode—not a claim that every website can be copied perfectly. Static HTML works best; JavaScript is removed for safety, and sites that require login or client-side rendering may not display completely. Try the live demo at halloween-decor.onrender.com https://halloween-decor.onrender.com . You can also run the app locally with the built-in provider, which works without API credentials: python -m venv halloween env .\halloween env\Scripts\Activate.ps1 python -m pip install -r requirements.txt Copy-Item .env.example .env python run.py Then open http://127.0.0.1:5000 . The demo helper pre-warms three sample pages before starting the server: python scripts\demo.py The source is organized around a few focused pieces: app/parser.py reads and validates the design response. app/pipeline.py coordinates provider calls, retries, fallback, and CSS sanitization. app/content/themes.py and app/content/decor/ hold the curated themes and individual SVG decorations. app/steps/assemble.py places decorations into the prepared page. app/ init .py provides the Flask routes, bounded background jobs, cache, and request limits. The project also includes a fixture matrix that checks five sample pages across all three intensity levels: python scripts\matrix.py --provider fake I built the app in milestones, starting with a working upload-and-preview flow and adding themes, decorations, and reliability features as the project grew. The model does not generate HTML. Instead, it returns a small line-based design description, such as a theme choice and a few allowed decoration slots. Keeping markup and SVG assets hand-authored makes the output easier to validate and keeps the model focused on visual decisions. The provider interface supports OpenAI-compatible chat-completion APIs. That makes it possible to configure different compatible services without changing the app’s design pipeline. A primary provider can be followed by a secondary LLM; a deterministic sample provider and code-only design are available as further fallbacks. API credentials are configured server-side or supplied transiently for a request, rather than being saved in job results. For reliability, the app also has bounded background jobs, visible progress and errors, request limits, result caching, and a regeneration option. The fixture matrix exercises output preservation, decoration budgets, CSS filtering, and preview security headers. The test suite currently covers the parser, uploads, provider behavior, and app routes. For this project, open innovation means being able to experiment with different compatible models and providers while keeping the rest of the application stable. The provider can change; the design format, validation rules, curated decorations, and preview assembly remain under the project’s control. That separation also makes failure less dramatic. If a provider is down or returns a response the app cannot use, the user can still get a themed preview from the sample or code-only design. The app does not need to trust a model with arbitrary page markup to make something fun. The goal is small and cheerful: let someone take a page they know and see it wearing a Halloween costume. Maybe a familiar article gets a tiny moon in the corner, a pumpkin between sections, and a warmer palette—without losing the words that made the page theirs. It’s a playful way to make the web feel seasonal, one little decoration at a time.