{"id":6472,"date":"2026-08-26T20:23:23","date_gmt":"2026-08-26T20:23:23","guid":{"rendered":"https:\/\/www.upmyviews.com\/?p=6472"},"modified":"2026-09-11T13:23:27","modified_gmt":"2026-09-11T13:23:27","slug":"youtube-live-stream-latency-guide","status":"publish","type":"post","link":"https:\/\/www.upmyviews.com\/nl\/youtube-live-stream-latency-guide\/","title":{"rendered":"Normaal, laag of ultralaag? Kies de juiste latency voor YouTube Live."},"content":{"rendered":"<div class=\"upmymaintex\">\n<p>\u201cWhy is chat answering a question I asked 20 seconds ago?\u201d It is one of the most disorienting problems in a YouTube live stream. The host thinks the conversation is current, viewers are reacting to an earlier moment, and everyone begins talking past one another.<\/p>\n<p>The opposite problem can be just as damaging. A creator selects the fastest possible latency because it sounds better, but viewers encounter buffering, quality changes or interruptions that add little value to a mostly one-way presentation.<\/p>\n<p>YouTube live stream latency is not a simple speed setting. It is a production decision about how quickly information must travel between your broadcast and the audience. The right choice depends on the job of the stream, the importance of real-time responses, your connection stability, your desired resolution and the devices your viewers use.<\/p>\n<p>This guide provides an eight-part framework for choosing among normal, low and ultra-low latency. It also explains how to rehearse the viewer experience, diagnose delays and run a controlled test instead of making the decision from intuition alone.<\/p>\n<nav aria-label=\"Inhoudsopgave\">\n<ol>\n<li><a href=\"#define-interaction-loop\">Define the interaction loop before choosing a setting<\/a><\/li>\n<li><a href=\"#compare-latency-modes\">Compare normal, low and ultra-low latency<\/a><\/li>\n<li><a href=\"#match-format\">Match latency to your live-stream format<\/a><\/li>\n<li><a href=\"#audit-production-chain\">Audit the full production chain<\/a><\/li>\n<li><a href=\"#rehearse-viewer-experience\">Rehearse the stream as a viewer<\/a><\/li>\n<li><a href=\"#design-delay-tolerant-hosting\">Design hosting that survives delay<\/a><\/li>\n<li><a href=\"#diagnose-live-problems\">Diagnose buffering, late chat and desynchronization<\/a><\/li>\n<li><a href=\"#run-latency-experiment\">Run a three-stream latency experiment<\/a><\/li>\n<\/ol>\n<\/nav>\n<h2 id=\"define-interaction-loop\">Define the interaction loop before choosing a setting<\/h2>\n<p>Begin with the conversation, not the control panel. What exactly will a viewer do, and how quickly must the host observe and respond to that action?<\/p>\n<p>An interaction loop has four stages:<\/p>\n<ol>\n<li>The host says or does something that invites a response.<\/li>\n<li>The encoded video reaches the viewer.<\/li>\n<li>The viewer interprets the prompt and responds through chat or another mechanism.<\/li>\n<li>The host sees that response and reacts on camera.<\/li>\n<\/ol>\n<p>Stream latency affects only part of this loop. Viewers also need time to understand the prompt, type an answer and send it. The host then needs to notice the message, decide whether to use it and produce a response. A faster technical setting cannot fix a host who checks chat once every five minutes.<\/p>\n<p>Classify each planned interaction as <strong>immediate<\/strong>, <strong>periodic<\/strong> of <strong>nonessential<\/strong>.<\/p>\n<ul>\n<li><strong>Immediate:<\/strong> The next action depends on viewers\u2019 answers. Examples include live coaching, game choices, auctions, rapid Q&amp;A and audience-controlled demonstrations.<\/li>\n<li><strong>Periodic:<\/strong> The host checks responses at planned intervals. Examples include workshops, interviews with question breaks, tutorials and panel discussions.<\/li>\n<li><strong>Nonessential:<\/strong> Chat creates community, but it does not change the broadcast. Examples include speeches, performances, ceremonies and prerecorded presentations transmitted live.<\/li>\n<\/ul>\n<p>This classification prevents a common mistake: treating the existence of live chat as proof that ultra-low latency is necessary. A chat box may be active while the actual program remains one-way.<\/p>\n<p>Write one sentence describing the loop before configuring the stream. For example: <em>Every ten minutes, I will collect three questions, answer them together and return to the lesson.<\/em> That format can tolerate more delay than: <em>Viewers will vote on the next move, and I will act as soon as the result appears.<\/em><\/p>\n<p>If you cannot describe a meaningful interaction loop, prioritize a stable viewing experience over the smallest possible delay.<\/p>\n<h2 id=\"compare-latency-modes\">Compare normal, low and ultra-low latency<\/h2>\n<p>YouTube provides normal, low and ultra-low latency options for eligible encoder-based streams. Its official explanation of <a href=\"https:\/\/support.google.com\/youtube\/answer\/7444635\" target=\"_blank\" rel=\"noopener\">YouTube live-streaming latency<\/a> describes normal latency as the quality-oriented choice for non-interactive broadcasts, low latency as a balance for limited interaction, and ultra-low latency as the option for highly interactive conversation.<\/p>\n<table>\n<thead>\n<tr>\n<th>Mode<\/th>\n<th>Beste startgebruik<\/th>\n<th>Main advantage<\/th>\n<th>Belangrijkste compromis<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Normal latency<\/td>\n<td>Performances, conferences, presentations and passive viewing<\/td>\n<td>More playback buffer and broad feature support<\/td>\n<td>Slower host-viewer conversation<\/td>\n<\/tr>\n<tr>\n<td>Low latency<\/td>\n<td>Interviews, lessons, webinars and scheduled Q&amp;A breaks<\/td>\n<td>A practical balance between interaction and resilience<\/td>\n<td>Less room to absorb network instability<\/td>\n<\/tr>\n<tr>\n<td>Ultra-low latency<\/td>\n<td>Rapid Q&amp;A, audience-controlled content and direct conversation<\/td>\n<td>The fastest interaction loop<\/td>\n<td>Greater sensitivity to connection and playback problems<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>YouTube states that most viewers of a low-latency stream experience less than 10 seconds of latency, while most viewers of an ultra-low-latency stream experience less than five seconds. These are not promises for every viewer. Geography, internet conditions, devices, player behavior and the broadcast chain can produce different experiences.<\/p>\n<p>There is also a resolution trade-off. According to the same YouTube documentation, low and ultra-low latency do not support 4K, while normal latency supports all resolutions and live features. That matters when visual detail is central to the stream. A product demonstration, technical drawing session or premium performance may gain more from image clarity and stable playback than from near-real-time chat.<\/p>\n<p>Do not interpret the labels as a quality ranking. \u201cUltra-low\u201d is not the premium version of \u201cnormal.\u201d Each mode optimizes for a different job.<\/p>\n<p>A useful default is:<\/p>\n<ul>\n<li>Start with normal when viewers mainly watch.<\/li>\n<li>Start with low when viewers periodically contribute.<\/li>\n<li>Start with ultra-low only when fast back-and-forth interaction materially improves the content.<\/li>\n<\/ul>\n<p>Webcam and mobile live streams have platform-managed interactivity settings rather than the same selectable latency control available in an encoder workflow. Confirm what your chosen broadcasting route exposes before building a production plan around a setting you may not be able to change.<\/p>\n<h2 id=\"match-format\">Match latency to your live-stream format<\/h2>\n<p>The same channel may need different latency modes for different shows. Avoid creating one permanent rule such as \u201cwe always stream on ultra-low.\u201d Instead, make the choice at the format level.<\/p>\n<h3>Interviews and panel discussions<\/h3>\n<p>Low latency is usually a sensible starting point when the host collects audience questions but the guest conversation remains the main event. Ask viewers to submit questions during a segment, then have a producer group them for a later Q&amp;A block. Ultra-low latency becomes more valuable when guests directly converse with individual viewers throughout the show.<\/p>\n<h3>Classes, tutorials and workshops<\/h3>\n<p>Choose based on whether viewers must confirm understanding before you continue. A lecture with question breaks can tolerate low or even normal latency. A troubleshooting workshop in which a student reports a result and the instructor chooses the next step benefits more from ultra-low latency.<\/p>\n<h3>Gaming<\/h3>\n<p>Ultra-low latency can support audience choices, live challenges and direct player-chat conversation. However, normal or low latency may be preferable when production stability, high visual quality or uninterrupted gameplay matters more than immediate responses. Competitive content may also require an intentional delay to reduce the risk of viewers using the broadcast to gain real-time information.<\/p>\n<h3>Performances and ceremonies<\/h3>\n<p>Normal latency is generally the stronger starting point. Applause emojis and chat reactions do not normally alter the music, speech, service or award presentation. Give viewers the most resilient experience unless audience input changes what happens on stage.<\/p>\n<h3>Product launches and demonstrations<\/h3>\n<p>Separate the presentation from the support desk. A carefully produced launch may favor normal latency and high resolution, followed by a low- or ultra-low-latency Q&amp;A stream. Trying to optimize one broadcast for cinematic presentation and immediate technical support can force unnecessary compromises.<\/p>\n<h3>Watch-alongs and reaction streams<\/h3>\n<p>Synchronization matters as much as raw speed. If viewers are watching another source, provide a visible reference point, timer or verbal sync cue. Different viewers may still be at different points because pausing, buffering and device behavior alter individual playback positions.<\/p>\n<p>Research into crowdsourced live streaming has identified a disparity between broadcast delay and the faster delivery of live messages, which can disrupt interactive experiences. The authors\u2019 <a href=\"https:\/\/www.cs.sfu.ca\/~jcliu\/Papers\/UnderstandingCrowdsourced.pdf\" target=\"_blank\" rel=\"noopener\">measurement study of interactive live streaming<\/a> reinforces an important production lesson: chat can appear current even when participants are not seeing the same video moment.<\/p>\n<p>Choose the mode that protects the defining value of the format. If removing rapid chat would not meaningfully weaken the show, ultra-low latency is probably solving the wrong problem.<\/p>\n<h2 id=\"audit-production-chain\">Audit the full production chain<\/h2>\n<p>Latency does not begin and end at YouTube. Your camera, capture hardware, audio processing, encoder, local network, upload connection, platform ingestion and viewer playback can each add delay or instability.<\/p>\n<p>Map the chain in order:<\/p>\n<ol>\n<li>Camera and microphone capture the event.<\/li>\n<li>Capture devices transfer the signals to the production system.<\/li>\n<li>Software processes scenes, graphics, filters and audio.<\/li>\n<li>The encoder compresses the program.<\/li>\n<li>Your connection uploads it to YouTube.<\/li>\n<li>YouTube processes and distributes the stream.<\/li>\n<li>The viewer\u2019s device downloads and plays it.<\/li>\n<li>The viewer responds, and the message travels back to the host.<\/li>\n<\/ol>\n<p>When a stream feels late, creators often blame the platform setting without checking upstream delays. Some cameras, wireless links and capture cards introduce noticeable processing time. Audio filters can create a mismatch if their delay differs from the video path. Remote guests may arrive through software that adds another transmission loop before the program is even encoded.<\/p>\n<p>Reduce avoidable complexity before reducing platform latency. Disable visual filters that do not improve the show, close bandwidth-heavy applications, use a wired connection where practical, and avoid sending multiple unnecessary high-bitrate feeds from the same network.<\/p>\n<p>Review YouTube\u2019s current <a href=\"https:\/\/support.google.com\/youtube\/answer\/2853702\" target=\"_blank\" rel=\"noopener\">live encoder settings, bitrate and resolution guidance<\/a> rather than copying a random preset from an old tutorial. A bitrate that is too ambitious for your connection can create instability, while an unnecessarily low bitrate can compromise image quality.<\/p>\n<p>Do not plan around the highest upload-speed result you have ever seen. Test under realistic conditions: the same room, time of day, network users, computer load, scenes, movement and audio routing expected during the real program. Leave operating headroom instead of trying to consume every available megabit.<\/p>\n<p>If you use remote guests, rehearse their connections too. A perfect studio upload cannot repair a guest\u2019s unstable Wi-Fi, overloaded laptop or poor microphone path. Give each participant a short technical checklist and an alternative way to reconnect.<\/p>\n<h2 id=\"rehearse-viewer-experience\">Rehearse the stream as a viewer<\/h2>\n<p>A clean encoder preview proves only that the program looks correct before transmission. It does not prove that viewers receive it smoothly or that conversation feels natural.<\/p>\n<p>Schedule an unlisted rehearsal and watch it from at least two viewer conditions:<\/p>\n<ul>\n<li>A computer on a network separate from the encoder, if possible.<\/li>\n<li>A phone using cellular data rather than the studio Wi-Fi.<\/li>\n<\/ul>\n<p>Do not judge delay with a vague impression. Use a repeatable marker. Hold a stopwatch or clock in the camera frame, say a numbered cue, and compare the source moment with its appearance on each viewer device. Repeat the check several times because delay can fluctuate.<\/p>\n<p>Then test the entire interaction loop. Ask a remote tester a simple question, wait for the reply in chat, acknowledge it on camera and have the tester report when that acknowledgment arrives. Record the approximate time for each stage.<\/p>\n<table>\n<thead>\n<tr>\n<th>Rehearsal check<\/th>\n<th>What it reveals<\/th>\n<th>Mogelijke reactie<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Source-to-viewer cue<\/td>\n<td>Broadcast delay on each test device<\/td>\n<td>Change latency mode or revise expectations<\/td>\n<\/tr>\n<tr>\n<td>Chat-to-host response<\/td>\n<td>Monitoring and moderation delay<\/td>\n<td>Improve chat placement or assign a producer<\/td>\n<\/tr>\n<tr>\n<td>Fast-motion scene<\/td>\n<td>Encoder and bitrate resilience<\/td>\n<td>Adjust resolution, frame rate or bitrate<\/td>\n<\/tr>\n<tr>\n<td>Thirty-minute stability run<\/td>\n<td>Heat, network or processing problems<\/td>\n<td>Simplify scenes or improve connectivity<\/td>\n<\/tr>\n<tr>\n<td>Phone playback test<\/td>\n<td>Realistic viewer-side quality<\/td>\n<td>Choose a more resilient configuration<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Keep the test unlisted rather than private when multiple testers need straightforward access, but treat the URL as controlled information. Do not include confidential visuals, credentials or unreleased material in the rehearsal.<\/p>\n<p>Review the recording afterward with the <a href=\"https:\/\/www.upmyviews.com\/nl\/youtube-video-analysator\/\">UpMyViews YouTube Video Analyzer<\/a> to identify packaging and presentation issues that are separate from latency. If the introduction feels slow on replay, a faster live setting will not make the underlying opening more compelling.<\/p>\n<p>This distinction also applies to audience retention. Use the methods in the guide to <a href=\"https:\/\/www.upmyviews.com\/nl\/youtube-audience-retention-analysis-guide\/\">reading YouTube audience retention like a growth analyst<\/a> when evaluating the archived stream. Technical delay may affect the live conversation, but pacing, structure and topic relevance still shape how replay viewers behave.<\/p>\n<h2 id=\"design-delay-tolerant-hosting\">Design hosting that survives delay<\/h2>\n<p>Good hosting can make moderate latency feel orderly. Poor hosting can make even a fast connection feel chaotic.<\/p>\n<p>The most important practice is to stop asking a question and immediately filling the silence. Viewers have not necessarily heard the question when the host begins complaining that nobody is answering.<\/p>\n<p>Use a deliberate prompt sequence:<\/p>\n<ol>\n<li>State the question in one clear sentence.<\/li>\n<li>Explain how viewers should answer.<\/li>\n<li>Repeat the available choices or place them on screen.<\/li>\n<li>Continue with a short, related point while responses arrive.<\/li>\n<li>Ask a producer or moderator to summarize the incoming answers.<\/li>\n<li>Acknowledge the delay before reacting to apparent contradictions.<\/li>\n<\/ol>\n<p>For example, instead of saying, \u201cWhich camera should I test? Tell me now,\u201d try: \u201cChoose camera A or camera B in chat. While your answers come in, I\u2019ll explain the lighting difference between them.\u201d The stream continues to deliver value while the loop completes.<\/p>\n<p>Use interaction blocks rather than constant interruption. A workshop might include eight minutes of instruction, two minutes for questions and a one-minute recap. This structure reduces the pressure to react to every message instantly and makes low latency sufficient for many formats.<\/p>\n<p>A moderator is especially valuable when chat volume grows. The moderator can collect repeated questions, identify corrections, flag technical reports and tell the host when responses belong to an earlier prompt. Give that person a private communication channel that does not appear in the public broadcast.<\/p>\n<p>Prepare reusable phrases for delay-sensitive moments:<\/p>\n<ul>\n<li>\u201cResponses to the previous question are still arriving, so I\u2019ll give it another moment.\u201d<\/li>\n<li>\u201cIf you joined late, we are choosing between the two options shown on screen.\u201d<\/li>\n<li>\u201cSome viewers may be a few seconds behind; avoid posting the result until I reveal it.\u201d<\/li>\n<li>\u201cI\u2019m grouping similar questions rather than answering them in arrival order.\u201d<\/li>\n<\/ul>\n<p>Also prepare the watch page before the event. The <a href=\"https:\/\/www.upmyviews.com\/nl\/youtube-beschrijvinggenerator\/\">YouTube-beschrijvinggenerator<\/a> can help create a clean starting draft for the schedule, topic summary, guest information and relevant resources. Edit the result manually so it accurately describes the live event and does not promise interactions you cannot deliver.<\/p>\n<p>If the stream serves as a major introduction to your brand, compare its opening promise with the questions in the <a href=\"https:\/\/www.upmyviews.com\/nl\/youtube-channel-trailer-diagnostic\/\">YouTube channel trailer diagnostic<\/a>. Live viewers need a similarly clear reason to stay, especially when they arrive in the middle of the program.<\/p>\n<h2 id=\"diagnose-live-problems\">Diagnose buffering, late chat and desynchronization<\/h2>\n<p>Do not change five settings after one bad stream. First identify which symptom occurred, who experienced it and when it began.<\/p>\n<h3>Viewers report buffering<\/h3>\n<p>Check whether complaints are widespread or isolated. Ask viewers to include their device and connection type, but do not turn the public chat into a lengthy support form. Review stream-health warnings and compare the timing of complaints with scene changes, motion-heavy segments or other network activity.<\/p>\n<p>If problems appear across many viewer reports, test a more resilient configuration. That may mean moving from ultra-low to low latency, lowering an unsustainable bitrate, reducing output demands or simplifying the production workload. If only one viewer reports trouble, the issue may be local to that viewer rather than the broadcast.<\/p>\n<h3>The host responds to old messages<\/h3>\n<p>Place chat close to the host\u2019s sightline, assign a moderator and label interactive segments. The problem may be attention latency rather than video latency. A host who reads from notes for ten minutes before checking messages will always sound behind.<\/p>\n<h3>Audio and video are out of sync<\/h3>\n<p>Test synchronization at the source, in the encoder preview and on a separate viewer device. A mismatch visible in the preview is upstream of YouTube. A mismatch appearing only after transmission requires further testing of the encoding and playback chain. Use a hand clap or another sharp visual and audio cue during rehearsal.<\/p>\n<h3>Different viewers see different moments<\/h3>\n<p>Expect some variation. Viewers may pause, rewind, recover from buffering or watch on different devices and networks. Avoid interactions that assume every person sees the exact same frame. Use verbal cues and on-screen labels instead of saying only \u201cright now\u201d or \u201clook at this.\u201d<\/p>\n<h3>The replay performs poorly<\/h3>\n<p>Latency settings are unlikely to be the primary explanation once the live event becomes an archived video. Review the opening, dead air, repeated questions, context for late arrivals and transitions between segments. Consider editing highlights or creating a separate concise video when the full live replay requires too much context.<\/p>\n<p>If you choose to add paid distribution after fixing the viewing experience, evaluate it as a separate acquisition decision. UpMyViews offers <a href=\"https:\/\/www.upmyviews.com\/nl\/\">YouTube-promotiepakketten<\/a> en een <a href=\"https:\/\/www.upmyviews.com\/nl\/koop-youtube-views\/\">YouTube views service<\/a>, but promotion cannot repair unstable playback, weak topic fit or confusing hosting. Review the service details, define a limited objective and judge results alongside organic traffic rather than assuming exposure guarantees channel growth.<\/p>\n<h2 id=\"run-latency-experiment\">Run a three-stream latency experiment<\/h2>\n<p>The best setting is the one that reliably serves your actual format and audience. Test it across comparable broadcasts instead of choosing it from a single rehearsal.<\/p>\n<p>Run three streams with the same recurring format:<\/p>\n<ol>\n<li>Use normal latency for the first stream.<\/li>\n<li>Use low latency for the second stream.<\/li>\n<li>Use ultra-low latency for the third stream, provided your resolution and production requirements allow it.<\/li>\n<\/ol>\n<p>Keep the topic type, day, approximate duration, promotion effort, equipment and host structure as consistent as practical. Do not test a quiet tutorial on normal latency and compare it with a celebrity interview on ultra-low latency. Topic demand would overwhelm the technical difference.<\/p>\n<p>Track a small set of observations:<\/p>\n<ul>\n<li>Approximate source-to-viewer delay on two test devices.<\/li>\n<li>Number and timing of buffering complaints.<\/li>\n<li>Stream-health warnings or connection interruptions.<\/li>\n<li>How long the host waited for responses.<\/li>\n<li>Number of useful audience contributions, not merely total chat messages.<\/li>\n<li>Whether interaction changed the content in a valuable way.<\/li>\n<li>Host and moderator workload.<\/li>\n<li>Replay quality and the amount of dead time created by waiting.<\/li>\n<\/ul>\n<p>After each stream, ask three questions:<\/p>\n<ol>\n<li><strong>Was the conversation fast enough for the format?<\/strong><\/li>\n<li><strong>Was playback stable enough for the audience?<\/strong><\/li>\n<li><strong>Did the lower delay create value worth the added production risk?<\/strong><\/li>\n<\/ol>\n<p>Select the slowest mode that still makes the intended interaction feel natural. This may sound conservative, but it preserves more playback cushion and discourages you from sacrificing stability for speed viewers do not need.<\/p>\n<p>Document the result as a format preset rather than a channel-wide rule. Your interview show might use low latency, your audience-controlled gaming stream might use ultra-low, and your annual presentation might use normal latency at a higher resolution.<\/p>\n<p>Revisit the decision when the format, equipment, connection, team or interaction design changes. A latency setting is not a growth tactic by itself. It is infrastructure for a particular kind of viewer experience. When that experience is clearly defined, properly rehearsed and measured across real broadcasts, the setting becomes much easier to choose.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>A practical eight-part framework for choosing normal, low or ultra-low YouTube live stream latency without sacrificing stability for unnecessary speed.<\/p>","protected":false},"author":1,"featured_media":4741,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-6472","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-social-media"],"_links":{"self":[{"href":"https:\/\/www.upmyviews.com\/nl\/wp-json\/wp\/v2\/posts\/6472","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.upmyviews.com\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.upmyviews.com\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.upmyviews.com\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.upmyviews.com\/nl\/wp-json\/wp\/v2\/comments?post=6472"}],"version-history":[{"count":1,"href":"https:\/\/www.upmyviews.com\/nl\/wp-json\/wp\/v2\/posts\/6472\/revisions"}],"predecessor-version":[{"id":6473,"href":"https:\/\/www.upmyviews.com\/nl\/wp-json\/wp\/v2\/posts\/6472\/revisions\/6473"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.upmyviews.com\/nl\/wp-json\/wp\/v2\/media\/4741"}],"wp:attachment":[{"href":"https:\/\/www.upmyviews.com\/nl\/wp-json\/wp\/v2\/media?parent=6472"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.upmyviews.com\/nl\/wp-json\/wp\/v2\/categories?post=6472"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.upmyviews.com\/nl\/wp-json\/wp\/v2\/tags?post=6472"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}