SVG in RFCs
The policy for including SVG drawings in RFCs, leaving the tooling details to the RFC Production Center.
Rossi, A., Brownlee, N., Mahoney, J., and M. Thomson, "SVG in RFCs", RFC 9896, DOI 10.17487/RFC9896, January 2026, <https://www.rfc-editor.org/info/rfc9896>.
@misc{rfc9896,
series = {Request for Comments},
number = 9896,
howpublished = {RFC 9896},
publisher = {RFC Editor},
doi = {10.17487/RFC9896},
url = {https://www.rfc-editor.org/info/rfc9896},
author = {A. Rossi and N. Brownlee and J. Mahoney and M. Thomson},
title = {{SVG in RFCs}},
pagetotal = 4,
year = 2026,
month = jan,
} RFC text
Contents
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
AI ELI5
On this page
§1Introduction
This document defines policy for including Scalable Vector Graphics (SVG) in the definitive versions of RFCs and the publication formats defined in RFC 9720. SVG was developed by the World Wide Web Consortium (W3C).
It takes the policy requirements from RFC 7996 but removes all requirements about using a specific SVG profile or implementation code. The RFC Production Center (RPC) decides on SVG tooling and implementation. It may use RFC 7996 as a starting point but is not bound by it.
The rules say what drawings are allowed, and the publishing team chooses the exact tools.
§2Policy Requirements
SVG drawings may help explain a concept, but they should not be its only representation. The text of the RFC should fully describe protocols, formats or architectures, and drawings should at minimum be consistent with it.
Drawings must not include animation or interactive features, and should include only limited reactive design elements such as scaling and dark/light mode. They must not contain pointers to external resources or executable script. They should be as accessible as possible, and the RPC refers to the W3C accessibility guidelines.
Authors may include multiple versions of an image in RFCXML, and each publication format should present the version best suited to it. SVG vocabulary and implementation may change over time, and changes need not stay backwards compatible, although compatibility is encouraged.
A drawing can help, but the words must still explain everything. Drawings should not move, run programs, or fetch things from elsewhere.
§3Implementation Guidance
The RPC may place technical and editorial constraints on SVG use, must document the acceptable usage, and must widely communicate changes to the RFC author community. It is expected to ask for community input before deciding and to explain its reasoning publicly.
Its implementation should try to allow drawings produced by widely used drawing tools, and should focus on specifying what is disallowed rather than exactly what is allowed. The RPC should periodically review its practices.
The publishing team has to write down its rules, listen to authors, and say what is not allowed instead of listing every allowed thing.
§4Security and IANA
The document states that it has no security considerations and no IANA actions. The ban on executable script and external resources in drawings is a policy requirement rather than a security section.
There is nothing risky here to warn about, though the rules do keep drawings from running programs.