Building a Searchable Style Reference Library Beyond SrefHunt

Midjourney's --sref flag is one of the most powerful features in the platform. Point it at a reference image or a saved style code and every generation inherits that visual DNA—colour palette, texture, lighting, composition tendencies. For teams who need consistent aesthetics across dozens or hundreds of outputs, it changed the game.

Naturally, communities sprang up to catalogue what different style codes produce. SrefHunt lets you browse and discover codes with visual previews. Midlibrary maintains a searchable gallery of styles organised by aesthetic categories. X/Twitter threads regularly surface hidden gems. These tools are genuinely useful for inspiration and discovery.

But discovery is only half the problem. What happens after you find a style you like?

The --sref Landscape in 2026

Style Reference has become central to how professionals use Midjourney. The ecosystem around it has three layers:

• The platform itself — Midjourney's web app includes saved styles and the Style Creator, which lets you create custom styles from reference images. The web app is fast, well-designed, and the Style Creator is a genuinely powerful tool for building consistent aesthetics.
• Community discovery tools — SrefHunt, Midlibrary, and social media communities have built extensive libraries of style codes with visual previews. They make it easy to browse thousands of styles and find ones that match a mood or direction.
• Your internal workflow — How your team actually selects, approves, tracks, and reuses styles across projects. This is where the gap lives.

The first two layers are well-served. The third is where teams consistently struggle.

Discovery Is Not Governance

Public style reference libraries solve an important problem: “What does this style code look like?” What they do not solve is the set of questions that matter once you are using styles in professional work:

• Which styles are approved for which client? — A style that works for an editorial blog may be entirely wrong for a corporate presentation
• Who approved this style, and when? — When a client questions visual consistency, you need an answer in seconds, not hours
• Has this style been modified? — If someone tweaked the reference image, the old version is gone unless you saved it separately
• Are team members using the same version? — Without a single source of truth, style drift is inevitable
• Which deliverables used which style? — Usage tracking does not exist in any public tool or in Midjourney itself

SrefHunt and Midlibrary were never designed to answer these questions. They are discovery tools, and excellent ones. The governance gap is a different problem that requires a different solution.

The Style Creator: Powerful but Siloed

Midjourney's Style Creator deserves specific mention because it is genuinely good at what it does. You upload reference images, adjust parameters, and generate a custom style code that produces consistent results. For creating styles, it is the best tool available.

The limitation is not quality but portability. Styles created in the Style Creator live inside midjourney.com. They are not searchable outside the platform. They cannot be exported as structured data. There is no approval workflow, no categorisation beyond what you mentally track, and no way to share a curated subset with a specific team or client.

For a solo creator, this is fine. You know your styles, you remember which is which, and your workflow lives entirely within Midjourney. For a team of five designers across three client accounts, it becomes a bottleneck. The Style Creator is a creation tool, not a management system.

Comparing Your Options

Each tool in the style reference ecosystem serves a different purpose. Understanding where each one excels—and where it stops—helps you decide what combination your workflow needs.

The takeaway is not that one tool replaces the others. SrefHunt and Midlibrary remain the best way to discover new styles. A spreadsheet or DAM picks up where discovery ends.

What a Governed Style Library Looks Like

Whether you build it in a spreadsheet, Notion, or a dedicated tool, a governed style library has five properties that distinguish it from a list of bookmarked codes:

1. Categorised Styles

Every style belongs to a category: brand core, project-specific, client-specific, or experimental. The category determines who can use it and for what. A designer browsing the library should immediately see which styles are approved for production versus which are still being explored.

2. Visual Previews with Controlled Prompts

A style code without a visual preview is useless for quick selection. But a single preview image is misleading—it shows one interpretation, not the style's range. Best practice is to render the same three to four prompts with every style code, creating a consistent comparison grid. Use prompts that test different content types: a portrait, a landscape, an abstract composition, and a product shot.

3. Approval Status and Ownership

Each style has a status: draft, approved, deprecated. Each has an owner: the person responsible for maintaining it and making update decisions. Approval is explicit—a style is not approved until someone with authority says it is, and that decision is recorded.

4. Usage Tracking

When a team member uses a style in a deliverable, that connection should be recorded. This does not need to be automatic—even a simple log of “Project X, Q2 social campaign, used Style Y” is valuable. The goal is answering the question every client eventually asks: “What style was used for my campaign?”

5. Export and Documentation

Your style library should be exportable. A CSV or JSON dump means you can include style references in project documentation, hand off to a client, or migrate to a different tool. Styles locked inside a single platform are a dependency, not an asset.

Building It Yourself: A Practical Approach

You do not need specialised software to start. A well-structured Google Sheet or Notion database handles the first fifty styles with minimal overhead.

The Spreadsheet Method

• Column A: Style code — The raw --sref value
• Column B: Name — Human-readable descriptor (“Warm Editorial”, “Clean Product 3D”)
• Column C: Category — Brand core / Project-specific / Client / Experimental
• Column D: Status — Draft / Approved / Deprecated
• Column E: Owner — Who maintains this style
• Column F: Preview link — URL to a shared drive folder containing the test grid images
• Column G: Notes — Use cases, known quirks, recommended --stylize values
• Column H: Version — v1.0, v1.1, v2.0

Create one tab per client or project. Use conditional formatting to colour-code approval status. Pin a “Quick Start” tab at the front with just the brand core styles and their preview links.

The Image Grid Method

Complement the spreadsheet with a shared image folder. For each style, create a subfolder named with the style code containing the test grid images. This gives your team the visual browse experience that a pure spreadsheet cannot provide. Name folders consistently: [code]_[name]_v[version]—for example, sref-warm-editorial_v1.0.

The Naming Convention

Agree on a naming format before you start cataloguing. A practical structure: [Client]-[Category]-[Descriptor]-v[Version]. Examples: “Acme-Brand-WarmEditorial-v2.1” or “Internal-Experimental-NeonGlitch-v1.0”. The format matters less than consistency. Pick one and enforce it.

When to Upgrade from Manual Tracking

The spreadsheet-plus-image-folder approach is a solid starting point. It is free, familiar, and sufficient for small teams. But there are clear signals that you have outgrown it:

• More than 50 active styles — Visual comparison in a folder structure becomes impractical. You spend more time navigating than selecting.
• Multiple team members editing the sheet — Version conflicts, accidental overwrites, and “who changed this?” questions multiply.
• Client brand requirements — When clients demand documentation of which styles were used in their deliverables, manual tracking becomes a liability.
• Onboarding friction — New team members take days to understand the style library because it requires institutional knowledge that is not captured in the spreadsheet.
• Cross-project style reuse — You know a style exists from a previous project but cannot find it without asking the original designer.

At this point, a DAM with visual browse, tagging, and collection-based organisation becomes a practical upgrade—not because spreadsheets are bad, but because the specific operations you need (visual search, faceted filtering, access control, audit trails) are what DAMs are purpose-built for. Numonic is one option. The important thing is that your tool supports visual discovery, structured metadata, and export.

Style References Deserve the Same Rigour as Any Design Asset

Nobody questions the need to organise fonts, colour palettes, and brand guidelines. Style references deserve the same treatment. They are not throwaway codes—they are the visual identity of your AI-generated work, and they accumulate quickly.

The tools for discovering styles are already excellent. What most teams are missing is the layer between discovery and production use: the governance, versioning, and discoverability that turns a collection of bookmarked codes into a reliable design system.

Start with an audit of what your team currently uses. Build the spreadsheet. Agree on naming. Decide who approves. The system does not need to be complex—it needs to exist.