RFC 9896 INFORMATIONAL PROCESS · FORMATS

SVG in RFCs

Policy for SVG drawings in RFCs, with tooling decisions assigned to the RFC Production Center.

On rfc-editor.org ↗
PUBLISHED
January 2026
AUTHORS
A. Rossi, N. Brownlee, J. Mahoney, M. Thomson
STREAM
Editorial
BUILDS ON
RFC 7996 — SVG RFC
SVG TOOLING DECISIONS
RFC Production Center
IANA ACTIONS
None
DOI
10.17487/RFC9896

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Editorial Stream                                                A. Rossi
Request for Comments: 9896                  RFC Series Consulting Editor
Obsoletes: 7996                                              N. Brownlee
Category: Informational
ISSN: 2070-1721                                               J. Mahoney
                                                   RFC Production Center
                                                              M. Thomson
                                                            January 2026


                              SVG in RFCs

Abstract

   This document defines policy for the inclusion of Scalable Vector
   Graphics (SVG) in the definitive versions of RFCs and relevant
   publication formats.  It contains policy requirements from RFC 7996
   but removes all requirements related to using a specific SVG profile
   or implementation code.  It also makes the RFC Production Center
   (RPC) responsible for decisions about SVG tooling and implementation.

   This document obsoletes RFC 7996.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the RFC Series Policy Definition
   Process.  It represents the consensus of the RFC Series Working Group
   approved by the RFC Series Approval Board.  Such documents are not
   candidates for any level of Internet Standard; see Section 2 of RFC
   7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9896.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction
   2.  Policy Requirements
   3.  Implementation Guidance
   4.  Security Considerations
   5.  IANA Considerations
   6.  Informative References
   Authors' Addresses

1.  Introduction

   This document defines policy for the inclusion of Scalable Vector
   Graphics (SVG) in the definitive versions of RFCs and relevant
   publication formats defined in [RFC9720].  It contains policy
   requirements taken from [RFC7996] but removes all requirements
   related to using a specific SVG profile or implementation code.

   SVG has been developed by the World Wide Web Consortium (W3C); see
   [SVG].

   The RFC Production Center (RPC) is responsible for making decisions
   about SVG tooling and implementation.  The RPC may use the content of
   [RFC7996] as a starting point for those decisions, but they are not
   bound by [RFC7996].  In addition, the RPC may change elements of the
   implementation as needed to support the RFC authoring community as
   long as those changes are aligned with the policy requirements in
   this document.

2.  Policy Requirements

   Decisions about SVG tooling and implementation are made by the RPC
   and must adhere to the policy requirements in this document:

   *  SVG drawings may be included in RFCs to help explain a concept
      more clearly, but they should not be the only representation of
      that concept.  A good-faith effort should be made to ensure that
      descriptions of concepts -- which might include protocols,
      formats, or system architectures -- are fully represented in the
      text of the RFC.  At minimum, SVG drawings should be consistent
      with the descriptions in the text of the RFC.

   *  SVG drawings must not include animation or interactive features.
      SVG drawings should include only limited reactive design elements
      (scaling, dark/light mode, and perhaps minor adjustments to allow
      for variations in display technology).  The intent of this is to
      ensure that the diagram's meaning is not altered.

   *  Images and diagrams in RFCs should be successfully rendered and
      understood by the widest audience possible.  To that end, the RPC
      may prohibit the use of SVG features that are known to lack
      support on common devices, that do not render on small or low-
      resolution screens, or that could make diagrams less
      comprehensible for any significant readership.  In particular:

      -  SVG drawings must not contain pointers to external resources.

      -  SVG drawings must not contain executable script.

      -  SVG drawings should be as accessible as possible to people with
         visual disabilities, including those who have color blindness,
         those who need to scale or change fonts, and those who use
         screen-reading software.  The RPC will refer to the W3C
         Accessibility Guidelines [WAI] when making decisions regarding
         accessibility.

   *  Authors may include multiple versions of images or diagrams in
      RFCXML [RFC9720].  Publication formats should present the versions
      best suited to each format.  In many cases, that will be an SVG.

   *  SVG vocabulary and implementation may change over time.  Changes
      are not required to remain backwards compatible, although
      maintaining compatibility where possible is encouraged.

   The RPC is authorized to place constraints on SVG usage in RFCs for
   both technical and editorial reasons in order to ensure that
   published RFCs meet the above policy and to provide consistency
   across the RFC Series.  The RPC must document the acceptable usage of
   SVG, and all changes to decisions about SVG tooling and
   implementation must be widely communicated to the RFC author
   community using mailing lists or other means.

3.  Implementation Guidance

   The RPC is expected to solicit community input before making
   decisions and to publicly explain their reasoning.

   Documentation produced by the RPC should describe the technical and
   editorial constraints that apply to SVG and provide RFC authors with
   guidance on how to produce diagrams that meet those constraints.

   The RPC's implementation should strive to allow SVG drawings produced
   by widely used drawing tools.  Where possible, implementation
   decisions should focus on specifying what is disallowed rather than
   attempting to specify exactly what is allowed.

   The RPC should periodically review and revise their practices.

4.  Security Considerations

   This document has no security considerations.

5.  IANA Considerations

   This document has no IANA actions.

6.  Informative References

   [RFC7996]  Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC",
              RFC 7996, DOI 10.17487/RFC7996, December 2016,
              <https://www.rfc-editor.org/info/rfc7996>.

   [RFC9720]  Hoffman, P. and H. Flanagan, "RFC Formats and Versions",
              RFC 9720, DOI 10.17487/RFC9720, January 2025,
              <https://www.rfc-editor.org/info/rfc9720>.

   [SVG]      W3C, "Scalable Vector Graphics (SVG) 2", 4 October 2018,
              <https://www.w3.org/TR/2018/CR-SVG2-20181004/>.

   [WAI]      W3C, "W3C Accessibility Standards Overview",
              <https://www.w3.org/WAI/standards-guidelines/>.

Authors' Addresses

   Alexis Rossi
   RFC Series Consulting Editor
   Email: rsce@rfc-editor.org


   Nevil Brownlee
   Email: nevil.brownlee@gmail.com


   Jean Mahoney
   RFC Production Center
   Email: jmahoney@staff.rfc-editor.org


   Martin Thomson
   Email: mt@lowentropy.net

ISO Plain Language

On this page
PROBLEMRFC 7996 combined policy about SVG drawings with requirements for a particular SVG profile and implementation code.
MECHANISMRFC 9896 keeps policy requirements, removes profile and implementation-code requirements, and assigns tooling decisions to the RFC Production Center.
STATUS TODAYThis Informational RFC obsoletes RFC 7996. SVG must not contain animation, executable script, or pointers to external resources, and cannot be the only representation of a concept.

§1Policy and Tooling Responsibility

This document sets policy for including Scalable Vector Graphics (SVG) in definitive RFC versions and relevant publication formats. It retains policy requirements from RFC 7996 but removes requirements tied to a specific SVG profile or implementation code.

The RFC Production Center (RPC) makes decisions about SVG tooling and implementation. It may use RFC 7996 as a starting point but is not bound by it.

This RFC sets rules for SVG drawings in RFC publications. The RPC chooses the tools and implementation details that follow those rules.

§2Requirements for SVG Drawings

SVG drawings may help explain a concept, but they should not be its only representation. The RFC text should fully represent protocols, formats, and architectures, and drawings must be consistent with that text.

SVG drawings MUST NOT contain animation, interactive features, pointers to external resources, or executable script. They should be accessible to a wide audience. Authors may include multiple image versions in RFCXML, and publication formats should present versions suited to each format.

A diagram can help explain a concept, but the RFC text must also explain it. SVG drawings must not animate, run scripts, or fetch external resources.

§3RPC Guidance and Review

The RPC may set technical and editorial constraints on SVG to ensure policy compliance and consistency across the RFC Series. It must document acceptable SVG usage and widely communicate changes to tooling and implementation decisions.

The RPC is expected to solicit community input and explain its reasoning publicly. Its implementation should support widely used drawing tools where possible and focus on describing what is disallowed. Practices should be reviewed periodically.

The RPC must document SVG rules and communicate changes to RFC authors. It should seek community input, explain decisions, and review its practices.

§4Security and IANA

The RFC states that it has no security considerations and no IANA actions. Its policy requirements still prohibit executable script and external resource pointers in drawings.

The document states that it raises no security considerations and requires no IANA actions. Its policy forbids SVG scripts and external resource pointers.

§5References