Creative media

Creative work deserves more than a temporary social post or a file on someone else’s platform. A personal website can present the work, explain the ideas behind it, preserve its history, and connect visitors to related projects.

A single creation often appears as several resources: a public page, a media file, a thumbnail, a download, and structured metadata. Those resources serve different jobs. Significant works can have permanent URLs so they can be linked, credited, and discovered apart from the gallery that lists them. You control which works you expose, how they look, and what rights you grant.

What exactly are you publishing?

Example: Morning Light is a photograph (the work). https://joshua.example/photography/morning-light/ is its page. /images/morning-light.webp is a visual encoding. A smaller grid image is a preview. /photography/ is a collection. An Instagram post would be a syndicated copy—not the same as the original page.

Photograph (work)
   |
   | described by
   v
Work page  ----preview---->  thumbnail / og:image
   |
   | presents
   v
Media file (JPEG / AVIF / …)

Do not conflate these layers.

1. Create You make the work and choose what to publish.
2. Page You give it a stable URL with human-readable context.
3. Represent You attach accessible media files and previews.
4. Describe You add credits, dates, Schema.org, and licenses as needed.
5. Collect You link it from galleries and indexes without replacing the work page.

Give each creation its own address

Stable URLs support linking, discovery, attribution, citation, accessibility, portfolio structure, syndication, preservation, and migrations.

/photography/
/photography/morning-light/
/photography/winter-river/

/music/
/music/first-recording/

/projects/
/projects/clockwork-garden/

/games/
/games/star-courier/

These paths are examples, not mandatory. A single gallery page with dozens of unlabeled images offers weaker linking and attribution than dedicated work pages. Decorative site chrome does not need its own work URL.

Semantic HTML for creative work

Useful elements include <main>, <article>, <section>, <figure>, <figcaption>, <img>, <picture>, <source>, <audio>, <video>, <track>, <a>, <time>, <details>, and <summary>. Prefer meaningful media over purely decorative presentation. See Semantic HTML.

Publish photography with context

A photograph page typically needs a title, description, creator, creation and/or publication dates, image representation, caption, alternative text, optional technique notes, collection links, copyright/license, and a canonical URL.

<article>
  <h1>Morning Light</h1>
  <figure>
    <img
      src="https://joshua.example/images/morning-light.webp"
      alt="Sunlight passing through the branches of an oak tree"
      width="1200"
      height="800"
    >
    <figcaption>
      Morning Light, a photograph by Avery Example.
    </figcaption>
  </figure>
  <p>A photograph taken during an early morning walk.</p>
  <p>
    <time datetime="2026-09-15">Sept. 15, 2026</time>
  </p>
  <p>
    <a href="https://joshua.example/photography/">Photography</a>
  </p>
</article>

The image shows the work; alt conveys essential visual information; the caption carries credit and context; surrounding prose can narrate. Link back to the collection and sideways to related works.

Responsive images and efficient delivery

Publish width/height, srcset/sizes, and optionally <picture> for formats or art direction. Use lazy loading and sensible fetch priority when appropriate. Compress thoughtfully; keep full-resolution downloads separate from grid thumbnails.

<img
  src="https://joshua.example/images/morning-light-800.webp"
  srcset="
    https://joshua.example/images/morning-light-400.webp 400w,
    https://joshua.example/images/morning-light-800.webp 800w,
    https://joshua.example/images/morning-light-1200.webp 1200w
  "
  sizes="(max-width: 40rem) 100vw, 40rem"
  alt="Sunlight passing through the branches of an oak tree"
  width="1200"
  height="800"
  loading="lazy"
>

<picture>
  <source
    type="image/avif"
    srcset="https://joshua.example/images/morning-light.avif"
  >
  <img
    src="https://joshua.example/images/morning-light.webp"
    alt="Sunlight passing through the branches of an oak tree"
    width="1200"
    height="800"
  >
</picture>

Resolution switching differs from art-directed crops. A thumbnail is not a substitute for a downloadable original. Measure performance; do not invent Core Web Vitals claims.

Make visual work understandable to more people

• Alternative text — essential information or purpose of the image in context (WCAG 2.2).
• Captions — authorship, location, narrative that may not belong in alt.
• Extended descriptions — complex works that need a longer text nearby.
• Titles — naming; not a substitute for alt.
• Embedded file metadata — optional; may be stripped by optimizers.

Decorative images should be marked so assistive tech can skip them. Filename or title alone is often insufficient as alt.

Image metadata: EXIF, IPTC and XMP

EXIF often records camera settings and capture times. IPTC Photo Metadata commonly carries creator, credit, copyright, and rights text. XMP embeds structured metadata in many formats. These can coexist. Embedded file metadata is not the same as webpage Schema.org or visible credits.

Useful fields include creator, credit line, copyright notice, rights statement, description, keywords, capture date, and digital source type. Optimizers may strip metadata. GPS and device identifiers create privacy risk—review before publishing.

Describe where media came from

C2PA Content Credentials can record signed provenance assertions about origin and processing history (bindings, edits, verification). Verification may establish integrity of signed claims; it does not prove a photograph depicts a true event or that every claim is accurate. Transformations can drop credentials.

As of this chapter’s verification, C2PA Technical Specification 2.4 (April 2026) is widely cited; later revisions (for example 2.5) may supersede it—check spec.c2pa.org. C2PA is optional; it is not required to publish creative work.

Describe images with Schema.org

Relevant types include CreativeWork, Photograph, VisualArtwork, ImageObject, ImageGallery, and MediaObject. A Photograph (or VisualArtwork) is the creative work; an ImageObject describes a particular image file/encoding.

Useful properties: name, description, creator, author, dateCreated, datePublished, image, contentUrl, thumbnailUrl, encodingFormat, width, height, caption, license, copyrightHolder, copyrightNotice, creditText, acquireLicensePage, mainEntityOfPage. Match visible content. Prefer stable @id values.

{
  "@context": "https://schema.org",
  "@type": "Photograph",
  "@id": "https://joshua.example/photography/morning-light/#work",
  "name": "Morning Light",
  "description": "Sunlight through oak branches on an early walk.",
  "url": "https://joshua.example/photography/morning-light/",
  "mainEntityOfPage": "https://joshua.example/photography/morning-light/",
  "dateCreated": "2026-09-15",
  "creator": {
    "@type": "Person",
    "name": "Avery Example",
    "url": "https://joshua.example/about/"
  },
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "image": {
    "@type": "ImageObject",
    "@id": "https://joshua.example/images/morning-light.webp#img",
    "contentUrl": "https://joshua.example/images/morning-light.webp",
    "encodingFormat": "image/webp",
    "width": 1200,
    "height": 800,
    "caption": "Morning Light, a photograph by Avery Example."
  }
}

Explain how your images may be used

Distinguish creator attribution, copyright ownership, notices, licenses, permission requests, commercial licensing, public-domain dedications, and Creative Commons deeds. Schema.org licensing properties and IPTC rights fields can agree with a human-readable notice. Google’s image licensing metadata guidance is vendor-specific—separate from the Schema.org vocabulary itself. Structured license data does not invent rights you lack; omitting a license does not make a work free to reuse.

Visual artwork and illustration

Paintings, drawings, digital illustration, and sculpture need title, medium, technique, dates, artist, description, representative image, optional dimensions, collection, exhibition notes, and rights. Types include VisualArtwork, Painting, Sculpture, CreativeWork, and ImageObject. An image of a painting is not the physical artwork—use separate identifiers when both matter.

Build collections without losing the individual works

Galleries and portfolios need landing copy, individual work links, navigation, dates, series, categories, thumbnails, captions, and canonical URLs. Schema.org helpers: CollectionPage, ImageGallery, ItemList, ListItem.

<section>
  <h1>Photography</h1>
  <ul>
    <li>
      <a href="https://joshua.example/photography/morning-light/">
        <img
          src="https://joshua.example/images/morning-light-thumb.webp"
          alt=""
          width="240"
          height="160"
        >
        Morning Light
      </a>
    </li>
  </ul>
</section>

Link to work pages, not only static files. Not every embedded image is a distinct creative work.

Give recordings and compositions their own pages

Separate musical composition, recording, album, playlist, performance, audio file, artist, and publisher. Schema.org types include MusicComposition, MusicRecording, MusicAlbum, MusicPlaylist, AudioObject, MusicGroup, and Person. Relate recordings with recordingOf, inAlbum, byArtist, composer, duration, audio, contentUrl, encodingFormat, and license as applicable.

Native HTML audio

<audio controls preload="metadata">
  <source
    src="https://joshua.example/audio/first-recording.opus"
    type="audio/ogg; codecs=opus"
  >
  <source
    src="https://joshua.example/audio/first-recording.mp3"
    type="audio/mpeg"
  >
  <a href="https://joshua.example/audio/first-recording.mp3">Download MP3</a>
</audio>

Offer transcripts for spoken word. Avoid autoplay. The player is not the descriptive page.

Albums and tracks

Album pages can list ordered tracks that each have their own URLs. Cover art, performers, composers, release dates, and credits belong on the album or track pages. Optional MusicBrainz IDs help interoperability only when they identify the real release—never invent catalog numbers.

Publish video on your own website

Give each video a stable page, title, description, creator, dates, poster, player, captions/transcript, duration, and structured data.

<video
  controls
  poster="https://joshua.example/images/short-film-poster.jpg"
  width="1280"
  height="720"
  preload="metadata"
>
  <source
    src="https://joshua.example/videos/short-film.mp4"
    type="video/mp4"
  >
  <track
    kind="captions"
    src="https://joshua.example/captions/short-film-en.vtt"
    srclang="en"
    label="English"
    default
  >
</video>

The poster is a preview, not a separate video work.

Captions, subtitles and transcripts

Captions, subtitles, transcripts, and audio descriptions serve different audiences (WCAG 2.2). Use WebVTT with <track>.

WEBVTT

00:00:01.000 --> 00:00:04.000
Waves against the pier at dawn.

00:00:05.000 --> 00:00:08.000
Avery: The tide table still holds.

VideoObject

Schema.org VideoObject may use name, description, thumbnailUrl, uploadDate, duration, contentUrl, embedUrl, creator, and publisher. Do not invent interaction counts. Google video structured data is vendor guidance. See Sitemaps for video sitemap extensions.

Podcasts and spoken-word media

Publish series and episode pages with hosts, guests, dates, duration, artwork, audio, transcripts, and feed enclosures. Types: PodcastSeries, PodcastEpisode, AudioObject. The episode page and RSS enclosure complement each other—see Feeds.

Show people what you’ve built

Software project pages can include purpose, screenshots, demos, platforms, version, dates, downloads, repository, docs, license, maintainer, and status. Distinguish SoftwareApplication / WebApplication / MobileApplication from SoftwareSourceCode. External store or GitHub links do not replace your project page’s identity.

Games and interactive projects

Describe title, screenshots, poster, trailer, demo, platforms, controls, accessibility notes, dates, creator, downloads, source, and license. Types: VideoGame, Game, SoftwareApplication, SoftwareSourceCode. Keep a descriptive HTML page outside the playable canvas so visitors (and text consumers) can learn the title and credits without executing the game. JSON-LD does not make a WebGL canvas accessible by itself.

WebGL and experiments

Surround canvas/WebGL/WebGPU work with title, description, preview, instructions, keyboard support, reduced-motion options, compatibility notes, loading/fallback content, credits, and a stable URL. Launch the experience from a clear link rather than leaving a bare canvas with no context.

Books, comics and written creative work

Use Book, CreativeWork, Article, ShortStory, and—where appropriate—ComicStory / related comic types on Schema.org (verify current type docs when publishing). Cover title, creators, publisher, dates, edition, optional ISBN (never fabricate), cover image, description, genre, language, series, samples, and purchase/download links. For comics, separate series indexes, installment pages, and panel images.

Credit the people who made the work

Creator, author, illustrator, photographer, composer, performer, producer, developer, collaborator, publisher, and copyright holder are different roles. Multi-person projects need explicit credits and links to profile pages. Do not infer collaboration from ordinary hyperlinks alone. See Identity.

Tell visitors what they may do with your work

Ownership, attribution, copyright, licensing, and technical access differ. Projects may mix licenses (open-source code with all-rights-reserved art). Publish human-readable notices, machine-readable links, and complete license texts. A downloadable file is not an unrestricted reuse grant. See Creative Commons.

Open Graph previews for creative work

Use valid ogp.me properties (og:title, og:type, og:url, og:description, og:image, og:image:alt, and media fields where applicable). Choose a representative preview. Tie it to the canonical work URL. Do not invent types like photograph or game—use documented Open Graph types (often website or article). See Open Graph.

Creative work in feeds and sitemaps

Announce releases via RSS/Atom/JSON Feed (enclosures/attachments/Media RSS as appropriate). List work pages in XML sitemaps; image/video sitemap extensions are optional vendor/protocol extensions. Keep identifiers consistent across feed item, page, and sitemap loc. See Feeds and Sitemaps.

Slash pages and creative collections

Common collection paths include /projects/, /work/, /portfolio/, /photography/, /gallery/, /art/, /comics/, /music/, /videos/, /podcasts/, /games/, /apps/, /books/, /experiments/. Conventions help organization; they do not by themselves type every child. Optional OPML slash-page manifests can advertise custom paths—see Slash pages and OPML. Renaming existing sites is not required.

Complete creative publishing example

Harbor Notes at joshua.example might include a homepage, About, /work/ index, /photography/ plus /photography/morning-light/, a music release, a video page, a game page, a software project, and a book page. One full photograph document ties the layers together:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Morning Light — Harbor Notes</title>
    <meta
      name="description"
      content="Sunlight through oak branches—a photograph by Avery Example."
    >
    <link
      rel="canonical"
      href="https://joshua.example/photography/morning-light/"
    >
    <meta property="og:title" content="Morning Light">
    <meta property="og:type" content="website">
    <meta
      property="og:url"
      content="https://joshua.example/photography/morning-light/"
    >
    <meta
      property="og:image"
      content="https://joshua.example/images/morning-light.webp"
    >
    <meta
      property="og:image:alt"
      content="Sunlight passing through oak branches"
    >
    <script type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@type": "Photograph",
        "name": "Morning Light",
        "url": "https://joshua.example/photography/morning-light/",
        "dateCreated": "2026-09-15",
        "creator": {
          "@type": "Person",
          "name": "Avery Example",
          "url": "https://joshua.example/about/"
        },
        "license": "https://creativecommons.org/licenses/by/4.0/",
        "image": "https://joshua.example/images/morning-light.webp"
      }
    </script>
  </head>
  <body>
    <main>
      <article>
        <h1>Morning Light</h1>
        <p>
          By
          <a rel="author" href="https://joshua.example/about/">Avery Example</a>
        </p>
        <figure>
          <img
            src="https://joshua.example/images/morning-light.webp"
            alt="Sunlight passing through the branches of an oak tree"
            width="1200"
            height="800"
          >
          <figcaption>Morning Light, September 2026.</figcaption>
        </figure>
        <p>
          Licensed
          <a href="https://creativecommons.org/licenses/by/4.0/">CC BY 4.0</a>.
        </p>
        <p>
          <a href="https://joshua.example/photography/">All photography</a>
        </p>
      </article>
    </main>
  </body>
</html>

Static hosting is enough—no required app JavaScript.

Hosting and performance considerations

Serve correct media types, caching headers, ETags, and Range support for large files. Prefer CDNs or object storage when needed, without locking into one vendor. Do not auto-load every original into a collection grid. Provide fallbacks for unsupported codecs. Inspect with curl -I.

Help your work outlive the platform that hosts it

Keep durable permalinks, redirects, original archives, backups, open formats, credit/license records, and dates. External embeds can vanish. Preserve descriptive pages even if a player moves. Migration checklist: inventory works → map URLs → redirect → move media → verify MIME/alt/JSON-LD → update feeds/sitemaps → spot-check OG images.

Security and privacy

Review EXIF/IPTC for GPS and private details; respect faces and locations; keep drafts private; verify upload types (not just extensions); treat SVG and untrusted media carefully; limit hotlinking abuse; distinguish publishing from authorizing automated reuse. For crawler and AI-preference signals, see Robots.

Creative media and the Joshternet

Independently published works help people explore photography, music, video, games, software, and books across member sites. Stable work pages, accurate types, and collection links assist compatible discovery systems. No HTML pattern guarantees Showcase placement.

Joshternet may harvest allowlisted Schema.org creative types, figures, creative-index links, and Open Graph on some index paths. It prefers work page URLs and excludes raw media-file URLs (and common upload trees). Chrome paths such as /uses/ and /about/ are not treated as creative works. Harvest is not Showcase: posters, dating rules, fairness caps, and kind filters still apply. Details: Reference.

Make sure your creative work can be understood

1. Validate HTML (Nu HTML Checker).
2. Validate Schema.org JSON-LD.
3. Check Open Graph fields and image reachability.
4. Review alt text, captions, keyboard access, and contrast.
5. curl -I media for status and MIME type.
6. Follow collection links to real work pages.
7. Align creation vs publication dates.
8. Confirm credits and licenses.
9. Inspect embedded file metadata for privacy.
10. Spot-check mobile and slow networks.
11. Rebuild unchanged works—URLs and dates should stay stable.

Common mistakes

Continue through the handbook

• Semantic HTML
• SEO fundamentals
• Slash pages
• Microformats2
• Open Graph
• Schema.org
• Feeds
• XML Sitemaps
• Identity and authorship
• Connections
• Events
• Validation
• Reference

Handbook navigation below follows content_nav (previous: Connections; next: Events).

Specifications and references